[Python-3000] packages in the stdlib

[Aaron Bingham]

Terry Reedy wrote:

>"Aaron Bingham" <bingham at cenix-bioscience.com> wrote in message 
>news:447F0FC4.1030906 at cenix-bioscience.com...
>  
>
>>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
--------------------------------------------------------------------