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