Eric Smith wrote:

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.

Thanks for pointing me to the that ticket. Looks like Guido already commented on this, so intobject.h could be revived in some form. Since this file would only be used by extension modules and possibly also include other helper macros, perhaps it'd be better to to rename the file to py2compat.h or something along those lines ?! We could then also have a py2compat.c to hold corresponding C code, e.g. to provide compatibility wrappers of new APIs that implement different semantics in 3.x. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 23 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/

Mark Dickinson wrote:

On Mon, Nov 23, 2009 at 10:44 AM, M.-A. Lemburg wrote:

...

Thanks for pointing me to the that ticket.

Looks like Guido already commented on this, so intobject.h could be revived in some form.

I'm wondering how a resurrected intobject.h should be used: would Linux distributors (for example) package up intobject.h with the rest of the python-devel RPM/package/whatever so that Python extension modules could just include it directly, or would it be better to encourage the extension writers to make a copy of intobject.h to add to the source for their extension?

In the first case, intobject.h would become a requirement for those extensions, so we'd presumably end up committed to either maintaining intobject.h for the lifetime of Python 3.x, or causing some pain when it does eventually get deleted.

I quite like Benjamin's suggestion (in the issue tracker) of putting it in Doc/includes.

I'm not sure whether Doc/ is a good location for such things. In the past, we've put such files in Misc/, e.g. the old Makefile.pre.in based extension mechanism was shipped that way: Extension writers would simply copy the file to their extension directory, create a Setup.in file and then have the users run "make -f Makefile.pre.in boot" to have a Makefile created which then built the extension. However, I'm not sure whether using the copy mechanism really works out that well: it's easier to just have the file(s) in the standard Python include file locations and then have extension writers use #include "py2compat.h" where necessary. Extension writer can then still use a private copy if needed, but most of the time they are probably better served by using the Python provided standard one.

...

Since this file would only be used by extension modules and possibly also include other helper macros, perhaps it'd be better to to rename the file to py2compat.h or something along those lines ?!

We could then also have a py2compat.c to hold corresponding C code, e.g. to provide compatibility wrappers of new APIs that implement different semantics in 3.x.

This is also an interesting idea.

-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 23 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/

I'm not sure concealing the differences between 2.x and 3.x behind such a wrapper is a good idea. It would be better if people became aware of / learnt about the new semantics.

+1. When porting a larger code base, I always came up with a custom set of macros, specific to the way the modules were written in the package I ported. In particular for PyString_, some of the code meant to deal with bytes, other code with text. There was no way to tell, short of reading and understanding the code. As you'll have to review the complete code, anyway, the savings you gain by using macros somebody else wrote are really minor. Regards, Martin

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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/casevh%40gmail.com

In an ideal world, developers would add that code to their extensions right away. In the real world, where developers only have limited resources available, you'll get more 3.x ports by making such ports as painless as possible while at the same time not forcing them to alienate their 2.x user base.

Unfortunately, such 3.x code would be full of bugs.

...

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.

That's not quite true: PyInt_AsLong(obj) will try the nb_int slot on non-integer objects which can return errors (it returns -1 and sets the error message).

However, the 2.x code will typically assume that the object is an int object, in which case PyInt_AsLong can never fail. So with intobject.h, the code will happily compile, but then fail to detect an exception at run-time - causing other difficult-to-find bugs. Regards, Martin