Re: [Python-Dev] standard libraries don't behave like standard 'libraries'
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 batteries included and ability to be changed after it > is discharged! ;) You can. You can simply delete any files in the standard library that you don't want. What is your usecase? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Removal of intobject.h in 3.1
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 by their PyLong_* neighbors. The best course of action here is using the PyInt_* functions aliased to PyLong_* found in intobject.h. """ However, intobject.h is no longer available. The checkin message for the removal says: """ r71697 | mark.dickinson | 2009-04-18 12:12:16 +0200 (Sat, 18 Apr 2009) | 3 lines The comments at the top of intobject.h say that it will be removed in 3.1. Make it so. """ 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. 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. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 21 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removal of intobject.h in 3.1
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.python.org/issue7353 You might want to comment there. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issue 1488943 - differ lib missing tab hinting
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 Hellewell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removal of intobject.h in 3.1
> 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 macros (unfortunately) allowed
to make non-obvious mistakes. Now that they are gone, people need to
really think of what precisely they want to do.
For example, consider
if (PyInt_Check(o)){
long val = PyInt_AsLong(o);
// process
} else if (PyLong_Check(o)) {
long long val = PyLong_AsLongLong(o);
// check for overflow
// process
}
With intobject.h, this code would continue to compile, but work
incorrectly, as the second case will never be executed. It would
be better to port this as
#if Py2.x
if (PyInt_Check(o)){
long val = PyInt_AsLong(o);
// process
} else
#endif
if (PyLong_Check(o)) {
i.e. eliminating the int case altogether. For another example,
long foo = PyInt_AsLong(Foo);
has a hidden error in 3.x, with intobject: PyLong_AsLong might
overflow, which the 2.x case doesn't.
So eliminating intobject.h likely helps avoiding subtle errors.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removal of intobject.h in 3.1
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 intobject.h header file.
>
> I think it's better than it sounds. The macros (unfortunately) allowed
> to make non-obvious mistakes. Now that they are gone, people need to
> really think of what precisely they want to do.
>
> For example, consider
>
> if (PyInt_Check(o)){
> long val = PyInt_AsLong(o);
> // process
> } else if (PyLong_Check(o)) {
> long long val = PyLong_AsLongLong(o);
> // check for overflow
> // process
> }
>
> With intobject.h, this code would continue to compile, but work
> incorrectly, as the second case will never be executed. It would
> be better to port this as
>
> #if Py2.x
> if (PyInt_Check(o)){
> long val = PyInt_AsLong(o);
> // process
> } else
> #endif
> if (PyLong_Check(o)) {
>
> i.e. eliminating the int case altogether. For another example,
>
> long foo = PyInt_AsLong(Foo);
>
> has a hidden error in 3.x, with intobject: PyLong_AsLong might
> overflow, which the 2.x case doesn't.
>
> So eliminating intobject.h likely helps avoiding subtle errors.
FWIW, I ported gmpy to Python 3.x without using intobject.h. I'm now
using the #if Py2.x ... #endif approach (almost) everywhere. The
same source compiles successfully with Python 2.4 to 3.2.
Case
>
> Regards,
> Martin
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/casevh%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
