Thoughts on some stdlib modules

[Ron_Adam]

On Sat, 09 Apr 2005 02:22:45 -0400, Steve Holden <steve at holdenweb.com>
wrote:

>Ron_Adam wrote:
>> On Fri, 08 Apr 2005 05:15:23 -0400, vegetax <vegeta.z at gmail.com>
>> wrote:
>> 
>> 
>>>Are those issues being considered right now? i cant find any PEP addressing
>>>the issue especifically, at least cooking it for python 3000.
>>>
>>>specific topics could be:
>>>
>>>grouping related modules.
>>>removing useless legacy modules.
>>>refactoring duplicated functionality.
>>>removing/redesigning poorly written modules.
>>>adding a module versioning system.
>> 
>> 
>> I've been thinking that the lib directory could be better named and
>> rearranged a bit.  I sometimes mistakenly open the libs directory
>> instead of lib because of the name similarity.
>> 
>> An alternative might be to use the name "packs" or "packages" in place
>> of "lib", which would emphasize the use of packages as the primary
>> method of extending python. The standard library could then be a
>> package called "stdlib" within this directory. Third party packages
>> would then be along side "stdlib" and not within a directory that is
>> within the standard library.
>> 
>> It would be mostly a cosmetic change, but I believe it would be worth
>> doing if it could be done without breaking programs that may have hard
>> coded path references to the library.  :-/
>> 
>> Ron
>> 
>Ron:
>
>You do a lot of thinking, don't you? :-)

Just the way my mind works. ;-)

>This is a *very large* change, not a cosmetic one, requiring changes to 
>many installation routines (including, probably, distutils) and causing 
>problems for software that attempts to operate with multiple versions of 
>Python - and those projects have problems enough as it is despite 
>Python's quite fine record of careful development.

I thought it might be more involved than it seemed.

>This seems a rather high price to pay just to avoid having you 
>mistakenly avoid opening "libs" instead of "lib" - a distinction that is 
>only meaningful on Windows platforms anyway, I believe.

That's not surprising on windows.  

>You are correct in suggesting that the library could be better organized 
>than it is, but I felt we would be better off deferring such change 
>until the emergence of Python 3.0, which is allowed to break backwards 
>compatibility. So, start working on your scheme now - PEP 3000 needs 
>contributions. My own current favorite idea is to have the current 
>standard library become the "stdlib" package, but I'm sure a lot of 
>people would find that suggestion at least as half-baked as yours.

Yes, I agree, the "stdlib" should be a package.  So I don't find it
half-baked at all.  Packages are part of python, so python should take
advantage of them.  

As far as a organizing scheme, I've come to the conclusion, files
should be organized by who's responsible for them, as in who to
contact if something doesn't work correctly. And not allowing files to
be intermixed from different sources is definitely worth doing if
possible.  Something Windows does very very badly.

For Python, that would mean packages should be fully self contained
and don't move any files to other directories if possible. Which
simplifies installs, uninstalls, and upgrades. But it would require
much more than a cosmetic change, and more than the simple, or not so
simple, directory changes I suggested.

One of the tools I wrote in C (early 90's), was a make file maker. I
still have the source code here somewhere.  Starting with the main
source file and a template with the compile options in it, it searched
all included files recursively for references and built the make file
using the template.  It really made large projects easy.  I don't
think that's anything new now.  Dist tools should do something like
that to find needed files.  It shouldn't matter what directories they
are in as long as it has read access rights to them, or they are in
the search path, or there's a direct or indirect reference to them in
the source code someplace.

>{If an idea is more-half-baked than something exactly half-baked is it 
>0.4-baked or 0.6-baked? Does "more half-baked" actually mean "less baked"?)
>
>regards
>  Steve

All new ideas are un-baked, they aren't fully baked until they are old
ideas which have been implemented. So 0.6 baked is more than half
baked, and 0.4 baked is ... pudding. ;-)

I'll consider working on that PEP. It sounds like it might be a good
project for me. 

Cheers,
Ron