James C. Ahlstrom wrote:
First, I am not all that opposed to having a notion of ".." available in the import statement. If we can write zope.dir1.mod1 which is a relative import going down, maybe we can write ../dir2/mod2 or something spelled differently. But I think there would still be problems.
We would be relying on all package authors to use ".." or "__" within their package. But it is more natural to write zope.this.that or mx.this.that everywhere, and that is what people have in fact done. Probably there would be bugs and at least annoyance.
Think of it as an opportunity: it makes intra-package imports very simple without hard-wiring paths to submodules into the package. In the end, having written a self-contained package is a "feature" of that package. Other authors can then say: ok, I can plugin your package if it's self-contained. -- I have a feeling that this discussion is loosing its grip on reality a bit. Jim and I are not argueing to change Python's face, internal structure or look&feel. The '__' thing doesn't harm anyone, doesn't break any functionality or code. It is even now already possible using import hooks and has been implemented before in ni.py using just that technology. All that we are talking about is reviving relative imports so that its usage is possible *without* adding yet another hook. This is not about the pros and cons of deeply nested packages and neither about advantages of shallow structures. Its only about adding semantics to the string '__' used in import statements. Nothing more. People are not forced to use it. Besides, if used it will be a package internal technique and not be visible to users of that package. Now why would anyone want to make life harder for package authors ? Give the people something to play with so that they have more fun at what their doing for the benefit of the community ! --
And it seems unfortunate to need this feature. A proper package scheme should really isolate package internals from the outside world, and if this isn't happening we need a new scheme.
I also don't think there is any escape from needing standard package names, at least the head name "zope" for example.
Of course all this currently works if (in Jim's example) both "zope" and "mx" are top-level names. Then the ".." is not necessary. But, as Jim points out:
But why shouldn't it be visible?
Because visibility has a cost. Making mx a top-level name means that someone else can't make it a top-level name. This is why packages are a good idea.
The global shared nature of PYTHONPATH and its name space makes it difficult to guarantee that all required packages are going to be present in a complicated installation like zope. And if anyone else installs another Python package, it can easily break the first installation.
One solution is for an application to establish its own PYTHONPATH which can not be altered. If this points to "zopedir" then the installer can freely install mx to the directory zopedir/mx and be confident that another mx installation is not damaged, nor used.
The logical extension is to place each package into its own file using a scheme like Gordon McMillan is using. If the package contents is obtained by seeking from the END of the file, then multiple package files can be concattenated with cat package1 package2 zope mx >> bigpackage and a large installation like zope can be shipped with its own "bigpackage" library which is essentially a normal PYTHONPATH archive with everything above the head directory names thrown away. The Python library is included under "Lib" just as it is now. The bigpackage library implies its own PYTHONPATH of "Lib;." If the Python library files are placed in the root, the implied PYTHONPATH is ".".
This is a possibility and in fact I'm using such a setup in my current application. 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). -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 108 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/