[Python-Dev] Removal of intobject.h in 3.1

[M.-A. Lemburg]

Mark Dickinson wrote:
> On Mon, Nov 23, 2009 at 10:44 AM, M.-A. Lemburg <mal at egenix.com> 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/