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