[Python-Dev] standard libraries don't behave like standard 'libraries'

Michael Foord fuzzyman at voidspace.org.uk
Thu Nov 12 11:15:11 CET 2009

Sriram Srinivasan wrote:
> I guess why every programming language has some kind of a 'standard
> library' built in within it. In my view it must not be called as a 
> 'library' at all. what it does
> is like a 'bunch of built-in programs ready-made to do stuff'.
> Lets see what a 'library' does:
> 1. offers books for customers
>  1.1 lets user select a book by genre, etc
>  1.2 lets user to use different books of same genre, etc
>  1.3 lets user to use books by same author, etc for different genre
> 2. keeps track of all the books + their genre
>  2.1 first knows what all books it has at present
>  2.2 when new book comes it is added to the particular shelf sorted by 
> genre,author,edition, etc.
>  2.3 when books become old they are kept separately for future reference
>  2.4 very old books can be sent to a museum/discarded
> I guess no standard library does the minimum of this but wants to be
> called a library.

I don't really understand your requirements, but it sound like you want 
a package management system. The standard library just provides a 
standard set of tools (it is the books not the book management system - 
although part of what you want is in the standard library in the form of 
distutils which is currently receiving a radical overhaul).

You should look at Distribute and virtualenv, which gets you pretty much 
what you are suggesting (as far as I can tell):


All the best,

Michael Foord

> As a python user I always wanted the standard library to have such
> features so the user/developer decides to use what set of libraries he
> want.
> consider the libraries for 2.5 ,2.6, 3K are all available to the user,
> the user selects what he wants with something like.
> use library 2.5 or use library 2.6 etc.
> The 2 main things that the library management interface has to do is
> intra library management and inter library management.
> intra library mgmt- consider books to be different libraries
> (standard, commercial, private, hobby, etc)
> inter library mgmt- consider books to be modules inside a library
> ( standard, commercial, private, hobby, etc)
> if somehow we could accomplish this kind of mother of a all plugin/ad-
> hoc system that is a real breakthrough.
> Advantages:
> 1. new modules can be added to the stream quickly
> 2. let the user select what he want to do
> 3. modules (that interdepend on each other) can be packed into small
> distribution and added to the stream quickly without waiting for new
> releases
> 4. solution to problems like py 2.x and 3.x
> 5. users can be up to date
> 6. documentation becomes easy + elaborate to users
> 7. bug managing is easy too
> 8. more feed back
> 9. testing also becomes easy
> 10. many more , i don't know.. you have to find.
> Python already has some thing like that __future__ stuff. but my
> question is how many people know that? and how many use that? most of
> them wait until old crust gets totally removed. that is bad for user
> and python. that is why problems like py2.x py3.x originate. If there
> is a newer book collection it must always be available at the library.
> i must not go to another library to get that book.
> I am not an expert, I am just another python learner. These are just 
> my views on the state of the standard libraries and to
> make them state-of-the-art..! ;)
> -- 
> Regards,
> Sriram.
> ------------------------------------------------------------------------
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk


More information about the Python-Dev mailing list