"Barry A. Warsaw" wrote:
"JF" == Jim Fulton <jim@digicool.com> writes:
JF> It actually does now, although that is bad. What if some JF> future python distribution has a Products package? Or a JF> Products.py?
Wouldn't collide, because in my scheme, Shared isn't a package, it's a directory on sys.path. Everything inside Shared is a top-level package. You'd never "import Shared.DC.ZRDB" but instead you would "import DC.ZRDB".
I wasn't talking about your scheme. I was talking about how I thought it should be.
>> A user would drop the kjParsing directory into Shared, and then >> all the import kjParsing.kjParser statements would Just Work.
JF> But then they'd be dumping kjParsing into the global package JF> namespace. Eventually, there will be collisions.
Do you really think so?
Yes.
Someone else is going to write a kjParsing module?
No, but sooner or later, two people are going to write two "Parsing" packages, or two "Oracle" packages or two .... Are you suggesting that package names should begin with some hash value to assure that they are unique? (What does kj stand for anyway? :) I guess we could use some form of GUID to be really safe .....
I think we're safe from this for the forseeable future through convention and peer pressure.
8^o (I feel like I should respond to this in some way but .... I just can't understand this kind of argument and don't know how to frame a response.)
Or is the concern that there will be two Products which use different versions of kjParsing?
No, at least not primarily.
I'm also not concerned here because if my product needs a very specific version of kjParsing I can't see any way around shipping my own version, subpackaging it, and using an absolute package name to ensure that I'm getting at exactly the one I need.
But even in this case, if you used a relative import, you *would* get the specific version you want. I give up. I'll just have to write some import hook to get the behavior I want in Zope. I will probably implement the second alternative I wrote about in my earlier document. I'll get Python to look at intermediate package paths before it looks at the main path. That way, any package that works as a top-level package will also work as a sub-package without modification. 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.