standard libraries don't behave like standard 'libraries'

[Diez B. Roggisch]

Sriram Srinivasan schrieb:
> On Nov 12, 3:56 pm, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
>> 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
> 
> I don't know if you have used Dev-C++.<http://www.bloodshed.net/dev/
> packages/index.html> It has a 'package management' mechanism for the
> standard libraries.

No, it hasn't. It has packages for *additional* libraries. C++ has only 
a very dim concept of standard-libraries. And those usually ship with 
the compiler, as standard-libraries shipped with python.

> please see the <http://devpaks.org/> webpage where all the packaged
> libraries are stored.
> 
> In python we have the PyPI which is equivalent to the http://devpacks.org
> but in PyPI the packages are mostly user made applications.
> What I want is similar to PyPI but for the python standard libraries,
> so that they (libraries) are as add-on as possible.
> check this out too.. <http://molhanec.net/devcpphelp/packages.php>

Why do you want that? What is the actual issue you are addressing? 
Python's strength is that it comes with a certain set of libs bundled. 
Artificially to unbundle them, forcing users to install them separatly 
makes little sense, if any. Sure, updating a bug might be *slightly* 
easier, but then the standard-libraries are well-tested and decoupling 
their evolving from the releases of the core interpreter opens up a 
whole can of worms of problems.

There is a tradeoff for both approaches, and one can argue if the 
current balance is the right one - but if so, then over concrete 
packages, not over the system in general.


Diez