On Sat, Nov 21, 2009 at 11:05 AM, "Martin v. Löwis" wrote:
>> IMHO, that's not really a good way to encourage people to try to provide
>> a smooth upgrade to the 3.x branch. Much to the contrary. 3.x should make
>> it easier for developers by providing more standard helpers like
>> the removed int
> IMHO, that's not really a good way to encourage people to try to provide
> a smooth upgrade to the 3.x branch. Much to the contrary. 3.x should make
> it easier for developers by providing more standard helpers like
> the removed intobject.h header file.
I think it's better than it sounds. The m
Is there anything holding up fixing issue 1488943? The bug was found and a
patch submitted 3 1/2 years ago. The patch is just a single line of code
(and some comment changes):
common = min(common, _count_leading(btags[:common], " "))
http://bugs.python.org/issue1488943
Thanks,
Phillip Hell
M.-A. Lemburg wrote:
Since package developers are just starting to port things to 3.x and
many appear to be considering supporting both 2.7 and 3.1 (including
myself), I find it a bit strange that such an import aliasing header
was removed in 3.1.
There's some discussion of this at http://bugs.
The wiki page for porting to 3.x says:
http://wiki.python.org/moin/PortingExtensionModulesToPy3k
"""
long/int Unification
In Python 3.0, there is only one integer type. It is called int on the Python
level, but actually
corresponds to 2.x's long type. In the C-API, PyInt_* functions are replaced
On Fri, Nov 13, 2009 at 09:59, Sriram Srinivasan
wrote:
> you were thinking wrong. If suppose this feature is introduced it doesn't
> mean python will become batteries removed!
> you can ship the python release with the 'standard library packages' already
> installed.
> so what we get here is batt