[Python-Dev] Relative Package Imports
Wed, 15 Sep 1999 18:49:38 -0400
"Barry A. Warsaw" wrote:
> >>>>> "JF" == Jim Fulton <email@example.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?
> Someone else is going to write a kjParsing
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.
(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 Fulton mailto:firstname.lastname@example.org 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