Assignment Versus Equality
Rustom Mody
rustompmody at gmail.com
Wed Jun 29 01:55:53 EDT 2016
On Wednesday, June 29, 2016 at 10:37:25 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Jun 29, 2016 at 2:51 PM, 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?
> >
> > ldo at theon:~> python3
> > Python 3.5.1+ (default, Jun 10 2016, 09:03:40)
> > [GCC 5.4.0 20160603] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> 2 ** 64
> > 18446744073709551616
> > >>> type(2 ** 64)
> > <class 'int'>
>
> The transparent shift from machine-word to bignum is what no longer
> exists. Both Py2 and Py3 will store large integers as bignums; Py2 has
> two separate data types (int and long), with ints generally
> outperforming longs, but Py3 simply has one (called int, but
> functionally like Py2's long), and does everything with bignums.
> There's no longer a boundary - instead, everything gets the "bignum
> tax". How steep is that tax? I'm not sure, but microbenchmarking shows
> that there definitely is one. How bad is it in real-world code? No
> idea.
>
> ChrisA
New to me -- thanks.
I thought it did an FSR type covert machine word → BigInt conversion under the hood.
Tax is one question
Justification for this change is another
More information about the Python-list
mailing list