Assignment Versus Equality

Rustom Mody rustompmody at gmail.com
Wed Jun 29 02:33:16 EDT 2016


On Wednesday, June 29, 2016 at 11:57:03 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Jun 29, 2016 at 3:55 PM, Rustom Mody wrote:
> >> 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
> 
> CPython doesn't currently do anything like that, but it would be
> perfectly possible to do it invisibly, and thus stay entirely within
> the language spec. I'm not aware of any Python implementation that
> does this, but it wouldn't surprise me if PyPy has some magic like
> that. It's PyPy's kind of thing.
> 
> It's also entirely possible that a future CPython will have this kind
> of optimization too. It all depends on someone doing the
> implementation work and then proving that it's worth the complexity.
> 
> ChrisA

Huh? I though I was just describing python2's behavior:

$ python
Python 2.7.11+ (default, Apr 17 2016, 14:00:29) 
[GCC 5.3.1 20160413] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x=2
>>> type(x)
<type 'int'>
>>> y=x ** 80
>>> y
1208925819614629174706176L
>>> type(y)
<type 'long'>


More information about the Python-list mailing list