Serhiy Storchaka added the comment:
Should it be backported to 2.7?
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3236
___
Benjamin Peterson added the comment:
It's only an optimization, so no.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3236
___
___
Benjamin Peterson [EMAIL PROTECTED] added the comment:
I suspect this is because of the transition from PyInt to PyLong:
Python 2.6b1+ (trunk:64580M, Jun 28 2008, 18:04:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type help, copyright, credits or license for more information.
Martin v. Löwis [EMAIL PROTECTED] added the comment:
For the old int type, implementing this was trivial, as the conversion
converted into a C long, then called PyInt_FromLong.
For long, it's much more tricky, as no C type can be used to store the
intermediate result. So instead,
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Le dimanche 29 juin 2008 à 17:43 +, Martin v. Löwis a écrit :
For long, it's much more tricky, as no C type can be used to store the
intermediate result. So instead, PyLong_FromString already allocates a
sufficiently-sized long object
Martin v. Löwis [EMAIL PROTECTED] added the comment:
The bug entry is just for pointing out a missed optimization
opportunity. The first mentioned solution would already be an
improvement, although of course it would even be better to skip the
intermediary allocation altogether.
Can you
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Le dimanche 29 juin 2008 à 21:52 +, Martin v. Löwis a écrit :
Can you propose an implementation strategy that doesn't create the
object, yet still avoids duplication of large chunks of code?
If by duplicating large chunks of code, you
