"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... 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. 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? Jim Ahlstrom