> On Sat, 25 Mar 2000, David Ascher wrote: > > > This made me think of one issue which is worth considering -- is there a > > mechanism for third-party packages to hook into the standard naming > > hierarchy? It'd be weird not to have the oracle and sybase > modules within > > the db toplevel package, for example. > > My position is that any 3rd party module decides for itself where it wants > to live -- once we formalized the framework. Consider PyGTK/PyGnome, > PyQT/PyKDE -- they should live in the UI package too... That sounds good in theory, but I can see possible problems down the line: 1) The current mapping between package names and directory structure means that installing a third party package hierarchy in a different place on disk than the standard library requires some work on the import mechanisms (this may have been discussed already) and a significant amount of user education. 2) We either need a 'registration' mechanism whereby people can claim a name in the standard hierarchy or expect conflicts. As far as I can gather, in the Perl world registration occurs by submission to CPAN. Correct? One alternative is to go the Java route, which would then mean, I think, that some core modules are placed very high in the hierarchy (the equivalent of the java. subtree), and some others are deprecated to lower subtree (the equivalent of com.sun). Anyway, I agree with Guido on this one -- naming is a contentious issue wrought with long-term implications. Let's not rush into a decision just yet. --david
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