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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4