Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Sage is not preparsing Python 3 integers

Hello, Sage community!

With the upcoming migration of Sage from Python 2 to Python 3 (really soon, let us hope!), there are some testings I have trying, and I have noticed that the "underscored integer literals", like "1_000_000" are not preparsed by Sage. For example,

preparse('1_000_000 + 3')

results in

'1_000_000 + Integer(3)'

However,

preparse('1000000 + 3')

returns

'Integer(1000000) + Integer(3)'

On the other hand, if I write

type(1_000_000 + 3)

the result is

<class 'sage.rings.integer.Integer'>

which is great, but

type(1_000_000 + 3_000)

instead gives me

<class 'int'>

Finally,

type(1000000 + 3000)

gives us

<class 'sage.rings.integer.Integer'>

I know one of the reasons for the Integer type was to allow divisions like 3/2 to return the float 1.5 even with Python 2, which would return (very disturbingly) 1, in other case. However, Python 3 integers already do this. Besides what I mentioned, I haven't found any difference in behavior.

So I was wondering: Is there any disadvantage in Sage not being preparsing this type of literals?

Sage is not preparsing Python 3 integers

Hello, Sage community!

With the upcoming migration of Sage from Python 2 to Python 3 (really soon, let us hope!), there are some testings I have been trying, and I have noticed that the "underscored integer literals", like "1_000_000" are not preparsed by Sage. For example,

preparse('1_000_000 + 3')

results in

'1_000_000 + Integer(3)'

However,

preparse('1000000 + 3')

returns

'Integer(1000000) + Integer(3)'

On the other hand, if I write

type(1_000_000 + 3)

the result is

<class 'sage.rings.integer.Integer'>

which is great, but

type(1_000_000 + 3_000)

instead gives me

<class 'int'>

Finally,

type(1000000 + 3000)

gives us

<class 'sage.rings.integer.Integer'>

I know one of the reasons for the Integer type was to allow divisions like 3/2 to return the float 1.5 even with Python 2, which would return (very disturbingly) 1, in other case. However, Python 3 integers already do this. Besides what I mentioned, I haven't found any difference in behavior.

So I was wondering: Is there any disadvantage in Sage not being preparsing this type of literals?

Sage is not preparsing Python 3 integers

Hello, Sage community!

With the upcoming migration of Sage from Python 2 to Python 3 (really soon, let us hope!), there are some testings I have been trying, and I have noticed that the "underscored integer literals", like "1_000_000" are not preparsed by Sage. For example,

preparse('1_000_000 + 3')

results in

'1_000_000 + Integer(3)'

However,

preparse('1000000 + 3')

returns

'Integer(1000000) + Integer(3)'

On the other hand, if I write

type(1_000_000 + 3)

the result is

<class 'sage.rings.integer.Integer'>

which is great, but

type(1_000_000 + 3_000)

instead gives me

<class 'int'>

Finally,

type(1000000 + 3000)

gives us

<class 'sage.rings.integer.Integer'>

I know one of the reasons for the Integer type was to allow divisions like 3/2 to return the float 1.5 1.5 even with Python 2, which would return (very disturbingly) 1, 1, in other case. However, Python 3 integers already do this. Besides what I mentioned, mentioned above and this, I haven't found any other difference in behavior.

So I was wondering: Is there any disadvantage in Sage not being preparsing this type of literals?

Sage is not preparsing Python 3 integers

Hello, Sage community!

With the upcoming migration of Sage from Python 2 to Python 3 (really soon, let us hope!), there are some testings I have been trying, and I have noticed that the "underscored integer literals", like "1_000_000" are not preparsed by Sage. For example,

preparse('1_000_000 + 3')

results in

'1_000_000 + Integer(3)'

However,

preparse('1000000 + 3')

returns

'Integer(1000000) + Integer(3)'

On the other hand, if I write

type(1_000_000 + 3)

the result is

<class 'sage.rings.integer.Integer'>

which is great, but

type(1_000_000 + 3_000)

instead gives me

<class 'int'>

Finally,

type(1000000 + 3000)

gives us

<class 'sage.rings.integer.Integer'>

I know one of the reasons for the Integer type was to allow divisions like 3/2 to return the float 1.5 even with Python 2, which would return (very disturbingly) 1, in other case. However, Python 3 integers already do this. Besides what I mentioned above and this, I haven't found any other difference in behavior.

So I was wondering: Is there any disadvantage in Sage not being preparsing this type of literals?