Guido van Rossum wrote:
- I'm not sure I care about having .so files inside packages on the filesystem; they are useful in Zope, but for very hackish reasons.
Why? If I write a package which is mostly in Python, it feels very natural to put the C extensions also in the package.
Just
Yes, it does, and as long as it works, I have no problem with that. Distutils supports this too, AFAIK. But if there are mechanical problems with making it work (zip files are a good example of that) I don't see why we should torture ourselves to get it to work when simpler solutions exist (such as putting the extension at the top level under a private name with the package name as a prefix). BTW, the hackish reasons I referred to are this: Zope often wants to *replace* existing extensions with its own versions, and places e.g. its own cPickle.so insize a package to force the import even if cPickle is built-in statically. But I'm not sure that that works if there's a toplevel cPickle.so which has already been imported; it may work on some systems but fail on others, depending on the shared library architecture (often one of the most hackish parts of user-space OS support). --Guido van Rossum (home page: http://www.python.org/~guido/)