At 02:10 PM 1/6/2008 -0800, Brett Cannon wrote: >My question becomes whether we want to allow something like this even >if we explicitly state people should not use this mechanism to >override pre-existing modules. Do we want people tossing stuff into >the 'databases' package, or should the packages in the stdlib be >considered sacred? This is actually an excellent point, given that the actual intended use of namespace packages is to allow an *organization* to control a namespace: e.g. zope.* and zc.* packages, osaf.* packages, etc. Using names that have meaning (like "email" or "databases") sort of goes against the whole point of namespace packages in the first place. For some reason, I wasn't thinking about that when the original post came through. So, now that I've thought about it, I'm -1 on the stdlib using *top-level* namespace packages to sort out its contents (e.g. "databases" as a top-level package name) If we want to allow separately-distributed *upgrades* or bugfix releases of projects (such as an updated sqlite module), then using 2nd-level namespace packages like "std.databases.*" would allow that. Note, by the way, that this implies that somebody creating their own Oracle driver would *not* be expected to put it into std.databases. Again, the whole point of a namespace package is to reserve that namespace for packages produced by a particular organization, similar to the way e.g. the 'org.apache.projectname' packages in Java work.
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