Assignment Versus Equality

Steven D'Aprano steve+comp.lang.python at pearwood.info
Wed Jun 29 01:26:32 EDT 2016


On Wednesday 29 June 2016 14:51, Lawrence D’Oliveiro wrote:

> On Wednesday, June 29, 2016 at 4:20:24 PM UTC+12, Chris Angelico wrote:
>>> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-
stupid/
>> 
>> """It would also be reasonable to assume that any sane language
>> runtime would have integers transparently degrade to BIGNUMs, making
>> the choice of accuracy over speed, but of course that almost never
>> happens..."""
>> 
>> Python 2 did this, but Python 3 doesn't.
> 
> Huh?


Chris is referring to the fact that in Python 2, there were two distinct 
integer types, int and long. Originally they were entirely independent, and int 
overflow would give you an exception:

# Python 1.5
>>> type(2147483647)         
<type 'int'>
>>> 2147483647 + 1
Traceback (innermost last):
  File "<stdin>", line 1, in ?
OverflowError: integer addition

To do BIGNUM arithmetic, you needed to explicitly specify at least one argument 
was a long:

>>> 2147483647 + 1L
2147483648L



but from about 2.4 or thereabouts, Python would automatically promote ints to 
longs when a calculation got too big:

# Python 2.7, 32-bit build
py> type(2147483647)
<type 'int'>
py> type(2147483647 + 1)
<type 'long'>


which is the behaviour JMZ is referring to.

BUT in Python 3, the distinction between int and long is gone by dropping int 
and renaming long as "int". So all Python ints are BIGNUMs.

In principle Python might use native 32 or 64 bit ints for small values and 
secretly promote them to BIGNUMs when needed, but as far as I know no 
implementation of Python currently does this.




-- 
Steve



More information about the Python-list mailing list