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