Mailing List Archive: Python: Dev

Re: standard libraries don't behave like standard 'libraries'

Index | Next | Previous | View Threaded

fuzzyman at voidspace

Nov 12, 2009, 2:15 AM

Post #1 of 9 (1033 views)
Permalink

Re: standard libraries don't behave like standard 'libraries'

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
> 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/

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

naughtysriram at gmail

Nov 12, 2009, 2:54 AM

Post #2 of 9 (980 views)
Permalink

Re: standard libraries don't behave like standard 'libraries' [In reply to]

>
> 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
>

I don't know if you have used
Dev-C++<http://www.bloodshed.net/dev/index.html%20>. It has a 'package
management' mechanism for the standard libraries.
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.orgbut in PyPI the packages are all 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.

I guess you understand what I am thinking... and do pardon my english too..

--

Regards,
Sriram.

ncoghlan at gmail

Nov 12, 2009, 4:26 AM

Post #3 of 9 (988 views)
Permalink

Re: standard libraries don't behave like standard 'libraries' [In reply to]

Matthew Wilkes wrote:
> There are plenty of other ways to manage this, most people use systems
> like virtualenv or buildout, but that's a discussion for the normal
> python mailing list, not the development one.

Indeed. Please take this to python-list (it isn't even a coherent enough
suggestion for python-ideas at this point - there are way too many
mistaken assumptions and/or unconventional uses of terminology)

Regards,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Nov 12, 2009, 11:38 AM

Post #4 of 9 (982 views)
Permalink

Re: standard libraries don't behave like standard 'libraries' [In reply to]

> 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..! ;)

If I understand correctly, you want the (current) standard library to be
separated from the Python implementation, and available separately.

Interestingly enough, people are very much split over whether that would
be a good thing or not. Some like it the way Python does, some dislike
it (and some quite strongly so).

In any case, many Python users consider it a good thing that it comes
"with batteries included", ie. with no need to add extra stuff for many
tasks.

Some of the Python maintainers have recently started objecting to this
setup, asking that the standard library should be split into separate
packages that are released and distributed independent of Python. Others
of us feel strongly that such a change should not be made.

So don't expect any immediate change to happen.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

jnoller at gmail

Nov 12, 2009, 11:57 AM

Post #5 of 9 (979 views)
Permalink

Re: standard libraries don't behave like standard 'libraries' [In reply to]

On Thu, Nov 12, 2009 at 2:38 PM, "Martin v. L�wis" <martin [at] v> wrote:
>> 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..! ;)
>
> If I understand correctly, you want the (current) standard library to be
> separated from the Python implementation, and available separately.
>
> Interestingly enough, people are very much split over whether that would
> be a good thing or not. Some like it the way Python does, some dislike
> it (and some quite strongly so).
>
> In any case, many Python users consider it a good thing that it comes
> "with batteries included", ie. with no need to add extra stuff for many
> tasks.
>
> Some of the Python maintainers have recently started objecting to this
> setup, asking that the standard library should be split into separate
> packages that are released and distributed independent of Python. Others
> of us feel strongly that such a change should not be made.
>
> So don't expect any immediate change to happen.
>
> Regards,
> Martin

Martin is correct; this came up on distutils-sig a month or so ago; I
proposed offering multiple downloads "with batteries" and "without
batteries (with the batteries on the side)". We decided as a group to
hold off on that until further in the future.

jesse
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

abpillai at gmail

Nov 13, 2009, 2:36 AM

Post #6 of 9 (961 views)
Permalink

Re: standard libraries don't behave like standard 'libraries' [In reply to]

On Fri, Nov 13, 2009 at 1:08 AM, "Martin v. Löwis" <martin [at] v>wrote:

> > 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..! ;)
>
> If I understand correctly, you want the (current) standard library to be
> separated from the Python implementation, and available separately.
>
> Interestingly enough, people are very much split over whether that would
> be a good thing or not. Some like it the way Python does, some dislike
> it (and some quite strongly so).
>
> In any case, many Python users consider it a good thing that it comes
> "with batteries included", ie. with no need to add extra stuff for many
> tasks.
>
> Some of the Python maintainers have recently started objecting to this
> setup, asking that the standard library should be split into separate
> packages that are released and distributed independent of Python. Others
> of us feel strongly that such a change should not be made.
>
> So don't expect any immediate change to happen.
>

I think the recent postings on "CPAN for Python" in this list also stems
from similar thoughts. As the size of the Python std library increases,
and when it reaches a kind of implosion point (perhaps it is there
already),
it does make sense to split it into some thing like a "core" group of
modules and add-ons which could be updated dynamically as and when
required by a tool.

It could be something as simple as a "require" keyword which could
pull in the depdencies if not found. Perhaps at the top of your module,

require (stuff, '1.27')
import stuff

Anyone who takes a quick look at the Python std library now is
sure to feel that there is an overkill of stuff there, which could be
classified and packaged better than dumping into the language
build.

> Regards,
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/abpillai%40gmail.com
>

--
--Anand

ncoghlan at gmail

Nov 13, 2009, 5:11 AM

Post #7 of 9 (957 views)
Permalink

Re: standard libraries don't behave like standard 'libraries' [In reply to]

Sriram Srinivasan wrote:
> http://pypi.python.org/pypi?%3Aaction=search&term=library&submit=search
> <http://pypi.python.org/pypi?%3Aaction=search&term=library&submit=search>
>
> this lists all the packages with the term 'library' in it.

Sriram,

Please take this discussion to catalog-sig - python-dev isn't the place
(the fact that many of us didn't immediately know the *right* place for
the discussion indicates where PyPI sits on our personal active level of
interest).

You should find more interested (and knowledgable) folks and catalog-sig.

Regards,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

Nov 13, 2009, 6:23 PM

Post #8 of 9 (948 views)
Permalink

Re: standard libraries don't behave like standard 'libraries' [In reply to]

Martin v. Löwis wrote:

> Some of the Python maintainers have recently started objecting to this
> setup, asking that the standard library should be split into separate
> packages that are released and distributed independent of Python. Others
> of us feel strongly that such a change should not be made.

I'd be worried, because I would no longer be able to
release an app or package and say "requires Python x.y".
I'd have to list the version numbers of all the micro
packages making up the standard library that I use.

Worse, I'd have to be aware of which ones I actually
*do* use so I could mantain that list, something I don't
have to think about at the moment.

It mightn't be so bad if the whole stdlib were a *single*
package, but I don't see much advantage in that.

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

kevin at bud

Nov 15, 2009, 8:19 PM

Post #9 of 9 (910 views)
Permalink

Re: standard libraries don't behave like standard 'libraries' [In reply to]

On Nov 13, 2009, at 6:23 PM, Greg Ewing wrote:

> Martin v. L�wis wrote:
>
> > Some of the Python maintainers have recently started objecting to
> this
> > setup, asking that the standard library should be split into
> separate
> > packages that are released and distributed independent of Python.
> Others
> > of us feel strongly that such a change should not be made.
>
> I'd be worried, because I would no longer be able to
> release an app or package and say "requires Python x.y".
> I'd have to list the version numbers of all the micro
> packages making up the standard library that I use.
>
> Worse, I'd have to be aware of which ones I actually
> *do* use so I could mantain that list, something I don't
> have to think about at the moment.

"requires Python x.y" would imply a dependency on the working set of
micro-packages which were shipped with that version of Python (or more
specifically, any working set that was released within a particular
Python release series). You would only need to list packages from the
standard library as dependencies in special-case circumstances where
you required a version higher or lower than what shipped with a
particular release series of Python.

It would perhaps increase the potential for people to get into
situations where they update a Python with newer packages which makes
it incompatibe with other Python applications. This problem would be
mitgated by the fact that the standard library tends to be very API
stable, so usually newer releases only contain minor bug fixes or
performance enhancements and are unlikely to cause breakage. Package
installation tools would also still continue to install into site-
packages, or ideally in a virtualenv or script-generation environement
like Buildout does. So installing updates to the standard library
could be done only to support those applications which require them,
but leave the default working set untouched for any other Python
applications. Conversely, it may also help the standard library
compatability in some situations, as I've seen people copy newer files
into the standard library locations as a method of applying bug fixes,
and given a better set of metadata it would then be more natural to
use tools which allowed updates to happen in an orderly fashion.

That's all given that splitting the standard library into individual
packages also continues to release a single standard library. I don't
really think releases small/medium/large sized standard libraries as
was also discussed is a good idea.

Maybe usage of tools such as virtualenv and buildout aren't yet
widespread enough to alleviate people mucking up their installations
in such a way that causes them pain. And this would also make it
easier for people to develop applications which would be harder to
pakcage into linux distributions or other package managers which don't
allow for non-global updates. However, these are only theoretical
concerns. It's concrete issue such as this one:

http://stackoverflow.com/questions/1734373/including-package-data-with-distribute/

Where a developer uses something in the standard library, and a python-
dev commiter provides a fix very quickly (yay Tarek!). But then that
developer has to be told to wait a year until the next Python release,
then wait until you've got the time to migrate the rest of your
application to the new Python release, then you can finally use that
fix, and in the meantime even though the issue has been solved you
still need to workaround the problem! It's issues like this where it's
hard not to want to avoid using standard library packages (beyond
"core" modules which stable and only change very rarely lke os, sys,
re, etc.) because there are unneccessary roadblocks between developer
and user.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads