[Python-Dev] Relative Package Imports

Barry A. Warsaw bwarsaw@python.org
Wed, 15 Sep 1999 18:07:34 -0400 (EDT)

>>>>> "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".

    >> 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
module?  I think we're safe from this for the forseeable future
through convention and peer pressure.

Or is the concern that there will be two Products which use different
versions of kjParsing?  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.
This is the approach Mailman takes.