On Fri, Nov 13, 2009 at 09:59, Sriram Srinivasan
naughtysri...@gmail.com 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
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
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
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
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
On Sat, Nov 21, 2009 at 11:05 AM, Martin v. Löwis mar...@v.loewis.de 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
