Mark Dickinson wrote: > On Mon, Nov 23, 2009 at 10:44 AM, M.-A. Lemburg <m...@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/ _______________________________________________ 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/archive%40mail-archive.com