[Python-checkins] r51492 - in python/branches/int_unification: Include/boolobject.h Include/intobject.h Include/longobject.h Modules/_sre.c Objects/abstract.c Objects/boolobject.c Objects/exceptions.c Objects/intobject.c Objects/listobject.c Objects/longobject.c Python/bltinmodule.c Python/marshal.c Python/pythonrun.c

[M.-A. Lemburg]

Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>>> Log:
>>> Drop the int type.
>>
>> Wouldn't it be better to add the long implementation on top
>> of the int implementation rather than replacing int with
>> long ?
> 
> There's a reason MvL is doing this on a branch - the idea is to
> benchmark the status quo (which he's done), merge int & long into a
> single type (which is naturally the current PyLong, as it is a complete
> functional replacement for int, albeit slower), and then optimise the C
> level integers *inside the long type*.
> 
> If the merged type can provide comparable performance to the two
> separate types, then it can become the 'int' type in Py3k, with 'long'
> being a historical relic existing only in the 2.x series.

I'm not questioning the merge itself, only its direction and that for
a few reasons:

* PyInts are very fast
* They are the most used object type in Python
* Lots and lots of extensions rely on them

* PyLongs are, well, slow compared to PyInts (they are still fast
  compared to other arbitrary precision implementations)
* PyLongs are only rarely used in Python, mostly in the cases
  where the PyInt range doesn't suffice and this use case is
  going to become even less important with 64bit platforms
  becoming a commodity
* PyLongs are often not expected/support by extensions

That said, I think it would be better to use the PyInt as
basis and merge the PyLongs into them instead of the
other way around, most important keep using a C long for
storing the value and only revert to the bytes array
(and the slower operations on it) in case needed.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 23 2006)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::