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 -- https://mail.python.org/mailman/listinfo/python-list