standard libraries don't behave like standard 'libraries'

[Diez B. Roggisch]

Sriram Srinivasan schrieb:
> 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.
> 
> 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.

You are greatly oversimplifying things, and ignoring a *lot* of issues 
here. The reason for __future__ is that it can *break* things if new 
features were just introduced. Take the with-statement, reachable in 
python2.5 throug

   from __future__ import with_statement

It introduces a new keyword, which until then could be happily used as 
variable name.

So you can't arbirtarily mix code that is written with one or the other 
feature missing.

Then there is the issue of evolving C-APIs (or ABI), wich makes modules 
incompatible between interpreters.

And frankly, for most of your list I don't see how you think your 
"approach" reaches the stated advantages. Why is documentation becoming 
easier? Why bug managing? Why testing?

I'm sorry, but this isn't thought out in any way, it's just wishful 
thinking IMHO.

Diez