[XML-SIG] Re: [Distutils] Disposition of C extensions and packages
Mon, 20 Dec 1999 00:06:58 +0100
"A.M. Kuchling" wrote:
> 1) A general Python question about packaging style: Is mixing
> C extensions and Python modules in one package tree a bad
> idea? It makes the whole tree platform-dependent, which is
> probably annoying for sites maintaining Python installation
> for different architectures.
I have been using that setup for two years now with all of
my mx extensions and so far it has been working great.
If you maintain packages with C extensions for several
platforms, you can simply install the packages under
the platform subdirs in /usr/local/lib/python1.5 -- one
copy for every platform. Disk space is no argument anymore
> 2) Another general question, this time o: how should this be
> handled? Should C extensions always be effectively
> top-level, and therefore go into site-packages? Should
> there be an xml package holding .py files, and an X package
> holding all the C extensions? (X = 'plat_xml',
> 'xml_binary', or something like that)
Just leave them in the package. I use a separate subpackage
for the C extension which the packages modules then import.
This makes mixed Python + C extensions and prototyping of
C APIs in Python very simple and straight forward.
> 4) Distutils question: is this a problem with the Distutils
> code that needs fixing? I suspect not; if the tools make
> it difficult to do stupid things like mix .py and .so
> files, that's a good thing.
I wouldn't like this; for a very simple reason: if someone
wants to provide a Python rewrite of a C module which works
as dropin replacement, the only way to handle this is by
having a .so file and a .py file with the same name in the
same directory. mxDateTime uses such a setup, for example.
Note that .so files are found before .py files, thus if
someone does have the .so file, Python will use the
C module and not the Python one.
Y2000: 13 days left
Python Pages: http://www.lemburg.com/python/