"Barry A. Warsaw" wrote:
JF> Zope products are python packages installed as sub-packages of JF> the Zope 'Products' packages. Products are generally JF> self-contained. If they need anything that's not part of JF> standard Python or standard Zope, they need to include it or JF> install what they need in a sub-package of another Zope JF> package, 'Shared'.
Jim, from your description, it sounds like Zope should be putting both the `Shared' and possibly `Products' directories on sys.path.
It actually does now, although that is bad. What if some future python distribution has a Products package? Or a Products.py? A product is actually a sub-package of Products. Even if Products was not a package, the Product would be and gadfly and kjParsong would be sub-packages. There is a similar issue with Shared, since Shared software is organized by organization, as in 'Shared.DC.ZRDB'.
Maybe it does and I'm still missing your point.
The point is that stuffing arbitrary things into a single global name space is bad. That's why packages were invented. Unless packages can be effectively nested, you haven't gained anything but time.
However if they are not, then wouldn't this solve your problem?
No, see above.
A user would drop the kjParsing directory into Shared, and then all the import kjParsing.kjParser statements would Just Work.
But then they'd be dumping kjParsing into the global package namespace. Eventually, there will be collisions. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.