Terry Reedy wrote: >"Aaron Bingham" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] > > >>I'm confused. As far as I can see, a reserved prefix (the "py" or >>"stdlib" package others have mentioned) is the only reliable way to >>avoid naming conflicts with 3rd-party packages with a growing standard >>library. >> >> > >True, but.. > > > >>I suspect we wll be going round and round in circles here as >>long as a reserved prefix is ruled out. IMO, multiple reserved prefixes >>("net", "gui", etc.) is much worse than one. >> >> > >But much better than a hundred or more ;-) > > The fewer the better of course.
>> Could someone please >>explain for my sake why a single reserved prefix is not acceptable? >> >> > >Because you have to type it over and over. > I tiny amount of pain for everyone to save a large amount of pain for a few (when their name gets used by a new stdlib package). >There are two separate issues being discussed here: >1) reducing/eliminating name clashes between stdlib and other modules; >2) organing the stdlib with a shallow hierarchy. > >For the former, yes, a prefix on stdlib modules would work, but this most >common case could/should be the default. > What the most common case is depends on what you are doing. For people writing one-off scripts, stdlib imports will dominate; in the code I work on, stdlib imports are only a small fraction (I'd guess about 10%) of all imports. >Requiring instead a prefix on all >*other* imports would accomplish the same. For instance, 's' for imports >from site-packages and 'l' for imports of local modules on sys.path (which >would then not have lib and lib/site-packages on it). > > True, but having the name of a module depend on how you choose to install it on a particular machine seems dangerous. >But the problem I see with this approach is that is says that the most >important thing about a module is where it comes from, rather than what I >does. > > Which is more important depends on what you are thinking about. If I am just trying to get something working quickly, what the module does is most important; if I am trying to minimize external dependancies, where the module comes from is most important. >For the latter (2 above), I think those who want such mostly agree in >principle on a mostly two-level hierarchy with about 10-20 short names for >the top-level, using the lib docs as a starting point for the categories > > That's fine with me, but I still think we need a top-level prefix. >Up in the air is the question of plugging in other modules not included in >the stdlib. With useful categories, this strikes me as a useful thing to >do. From a usage viewpoint, what a module does is more important than who >wrote it and who distributes it. > This strikes me as asking for naming conflicts. An alternative approach would be to have a system of categories for documentation purposes that are not related to the package names. Python could include support for searching by package category. >When it become trivial to grab and >install non-stdlib modules, then the distinction between stdlib and not >becomes even less important. > The distinction is still very important if I want my code to run with minimal fuss on anyone's machine. Cheers, -- -------------------------------------------------------------------- Aaron Bingham Senior Software Engineer Cenix BioScience GmbH -------------------------------------------------------------------- _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
