James C. Ahlstrom wrote:
"M.-A. Lemburg" wrote:
Still it doesn't avoid possible conflicts due to being top-level, e.g. the user could install an extension which relies on a specific top-level name already taken by the hosting package, e.g. the host defines a DateTime package and the extension comes with its own DateTime package. This is the current situation with Zope and mxODBC (which needs mxDateTime).
Yes, the name conflict at the global level is exactly the problem. And to repeat, I don't really mind if "__" is added to imports, although I don't like the spelling. But...
Doesn't look nice, but what other syntax would look better ? It will have to use identifiers and thus is restricted to [a-zA-Z0-9_]+.
Perhaps a better solution is a multiple global name space. Suppose there is a command line option (or other mechanism such as a special file in sys.executable) which specifies sys.path for the application. To be specific, suppose zope is installed in the "zopehome" directory and the zope package lives in zopehome/zope. And suppose zope needs mx, so it installs it in zopehome/mx. This really is an obvious structure, and anyone could see that replacing mx/* would upgrade the mx package. The sys.path would be zopehome plus perhaps some subdirectories of zopehome. Doesn't this solve the problem? Why not? And don't complain about wasted disk space. The smallest disk you can buy today is 4 gigs and costs $150.
This would solve the problem for Zope (but only after I have restructured my packages to all go under the mx package -- which is what started this thread; it wouldn't be needed using relative imports). But what about other installations or tools like mxCrypto which plug into existing packages (Andrew's crypto package) ? Today such plugins only work side-by-side, ie. you have to install one part which sits in the plugin slot and one part which gets installed somewhere in a top-level PYTHONPATH dir. The plugin slot part then imports the Real Thing from outside the host package (this is how mxCrypto integrates itself with AMK's lib).
I find the PYTHONPATH mechanism totally unreliable for commercial programs anyway. It is a global object, and an installation of a second Python program can break the first one. I don't think there is any solution to this other than specify sys.path on a per-application basis. If this is false, what is the other solution?
The solution I'm using (and Zope is too) is to wrap a complete Python installation into the product, all setup to do the right thing. It makes the archive a little heavier... which is actually not so bad from a marketing POV. Bizarre, but people seem to want all those megs. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 108 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/