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):
http://pypi.python.org/pypi/virtualenv
http://pypi.python.org/pypi/distribute
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
>
--
http://www.ironpythoninaction.com/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4