Gordon McMillan wrote: > > Andrew M. Kuchling wrote: > [snip] > > 2) Right now there's no way for third-party extensions to add > > themselves to a package in the standard library. Once Python finds > > foo/__init__.py, it won't look for site-packages/foo/__init__.py, so > > if you grab, say, "crypto" as a package name in the standard library, > > it's forever lost to third-party extensions. > > That way lies madness. While I'm happy to carp at Java for > requiring "com", "net" or whatever as a top level name, their > intent is correct: the names grabbed by the Python standard > packages belong to no one but the Python standard > packages. If you *don't* do that, upgrades are an absolute > nightmare. > > Marc-Andre grabbed "mx". If (as I rather suspect <wink>) he > wants to remake the entire standard lib in his image, he's > welcome to - *under* mx. Right, that's the way I see it too. BTW, where can I register the "mx" top-level package name ? Should these be registered in the NIST registry ? Will the names registered there be honored ? > What would happen if he (and everyone else) installed > themselves *into* my core packages, then I decided I didn't > want his stuff? More than likely I'd have to scrub the damn > installation and start all over again. That's a no-no, IMHO. Unless explicitly allowed, packages should *not* install themselves as subpackages to other existing top-level packages. If they do, its their problem if the hierarchy changes... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4