Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

standard libraries don't behave like standard 'libraries'

  

 
Python dev RSS feed   Index | Next | Previous | View Threaded


naughtysriram at gmail

Nov 12, 2009, 1:23 AM

Post #1 of 18 (1551 views)
Permalink
standard libraries don't behave like standard 'libraries'
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.
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.


eckhardt at satorlaser

Nov 12, 2009, 3:14 AM

Post #2 of 18 (1504 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
On Thursday 12 November 2009, Sriram Srinivasan wrote:
> I don't know if you have used Dev-C++. It has a 'package management'
> mechanism for the standard libraries.

I disagree. It has a package management system for libraries, not for the
standard libraries. The point is that the Python standard library is supplied
as part of Python itself, as is e.g. the C++ standard library as part of a
C++ compiler.

> In python we have the PyPI which is equivalent to the
> http://devpacks.org but in PyPI the packages are all user made
> applications.

...as in devpacks.org. Please scroll down on that page and read the warning
that mentions than any person can upload a package possibly containing
malware or broken code or whatever.

> What I want is similar to PyPI but for the python standard libraries, so
> that they (libraries) are as add-on as possible.

So, you want to make libs that are currently part of the standard library
external libs available via PyPI? If that is what you want, it would be
helpful if you provided a reason and also which libraries you're talking
about.

Uli

--
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**************************************************************************************
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************

_______________________________________________
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, 3:36 AM

Post #3 of 18 (1505 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
> I disagree. It has a package management system for libraries, not for the
> standard libraries. The point is that the Python standard library is
> supplied
> as part of Python itself, as is e.g. the C++ standard library as part of a
> C++ compiler.
>
>
standard libraries i meant the standard libraries used.
and what i asked for is for(in python) both the standard-libraries and the
standard libraries used.
c the term (intra and inter library management) which includes the default
standard libraries and other standard libraries


>
> ...as in devpacks.org. Please scroll down on that page and read the
> warning
> that mentions than any person can upload a package possibly containing
> malware or broken code or whatever.
>
>
if you talk about security then nothing is secure for sure!
in PyPI ppl can upload their application as egg.

what if there is another site where only eggs of python.org containing
add-on standard libraries are distributed
and noone is allowed to upload stuff except the python.org or PSF.

>
> So, you want to make libs that are currently part of the standard library
> external libs available via PyPI? If that is what you want, it would be
> helpful if you provided a reason and also which libraries you're talking
> about.
>
>
>
Not exactly via PyPI but something similar to it.
and don't compare C++ with python. both have their own + & -

--

Regards,
Sriram.


matthew at matthewwilkes

Nov 12, 2009, 4:03 AM

Post #4 of 18 (1506 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
On 2009-11-12, at 1136, Sriram Srinivasan wrote:

> standard libraries i meant the standard libraries used.
> and what i asked for is for(in python) both the standard-libraries
> and the standard libraries used.
> c the term (intra and inter library management) which includes the
> default standard libraries and other standard libraries

I don't think you're using the correct terminology. The standard
library is what is shipped with the interpreter. It's the only thing
that's common between all users of that interpreter, i.e. it's standard.

> what if there is another site where only eggs of python.org
> containing add-on standard libraries are distributed
> and noone is allowed to upload stuff except the python.org or PSF.

The PSF does not maintain add-on libraries, nor can it make guarantees
about other add-ons libraries.

>> So, you want to make libs that are currently part of the standard
>> library
>> external libs available via PyPI?
> Not exactly via PyPI but something similar to it.

Again, why?

> and don't compare C++ with python. both have their own + & -

Frankly, comparing and contrasting with other languages is very
useful, I have little to no idea what you're talking about, and doubt
it's got anything to do with the development of the Python language.

Matthew

_______________________________________________
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, 4:08 AM

Post #5 of 18 (1506 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
ok let me make it more clear..
forget how you use python now.. i am talking about __futuristic__
python programming.

these are just my ideas.. more over i can say imaginations.
there is no more python2.x or python3.x or python y.x releases. there
is only updates of python and standard library say 1.1.5 and 1.1.6.
let the difference be an old xml library updated with a new regex
support.

i am coding my program now.
i want my application to be compatible with 1.1.5 library

use library 1.1.5
import blah form blahblah
...
...

i cannot use regex feature of xml in this application
i then update my library in the evening
now both the libraries are present in my system.
now i try using the new feature

use library 1.1.6 #thats all now i get all features
import blah from blahblah
...
...

--

Regards,
Sriram.


matthew at matthewwilkes

Nov 12, 2009, 4:13 AM

Post #6 of 18 (1503 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
Oh, I see.

> use library 1.1.5

versus

> use library 1.1.6 #thats all now i get all features

That's part of pkg_resources. It looks like this:

pkg_resources.require("mylibrary==1.1.6")
import mylibrary

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.

Hope that helps,

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


regebro at gmail

Nov 12, 2009, 6:28 AM

Post #7 of 18 (1503 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
2009/11/12 Sriram Srinivasan <naughtysriram [at] gmail>:
> In python we have the PyPI which is equivalent to the http://devpacks.org
> but 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.

They are. The mechanism for deciding if you want to use them is called
"importing".

Now of you don't want them installed, the easiest is to remove the
ones you don't want. This is useful on embedded systems, etc, but not
generally useful otehrwise.

--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
_______________________________________________
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


g.brandl at gmx

Nov 12, 2009, 11:50 AM

Post #8 of 18 (1501 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
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.

I guess you're simply stretching the "library" metaphor far beyond its
usefulness :)

Georg

_______________________________________________
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 12, 2009, 11:35 PM

Post #9 of 18 (1493 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
On Nov 12, 2009, at 11:57 AM, Jesse Noller wrote:

> 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


It's also worth noting that there are three issues with respect to
standard library packaging which are all orthologous:

* Packaging for metadata: The standard library could be packaged so
that there is consistent metadata about the distributions which
compromise the standard library (version, author, maintainer, etc).
This could be useful so that it would be easier to see at a glance
which packages changed between any two Python releases. For example, I
have a script which compares two working sets of packages and
generates a web page with a colour-coded list of differences between
those two working sets, based on the size of the version number bump,
e.g. major.medium.minor (doesn't work with packages which use odd
version numbering schemes). I've used this to compare working sets
between different Grok releases or Plone releases to help see where
the activity or major API changes might be happening inside any given
Zope-based release. However, this script only works on 80% of the
code, the other 20% is in the standard library, which is currently a
black-box.

Also, if PEP 376 is accepted, then the standard library will be
inviolation of the stanard metadata for installed packages unless this
happens.

* Packaging for release: The standard library could be packaged so
that releases happen on PyPI. This could be useful so that it's easier
to consume newer versions of a package before those packages are
included in the next Python release. It could also make Python
upgrades easier, as you could hold-back packages which might otherwise
break an application upon upgrade. I happened to find a bug in a
standard library package today, and currently my option is to: Submit
bug report to PyPI, wait for Python 2.7 release, then wait for Plone
to update to Python 2.7. I'm looking at many years before this fix
goes into my production application, so in the meantime I need to
maintain a work-around for the bug as well account for the day when
this bug is fixed. It makes a mess of the code. If it was possible to
release this package on PyPI, this could reasonably happen in a few
days or at worst a couple months. The setup.py for that package could
be updated to require the newer version of the package, and the
workaround could be removed from the code.

* Packaging for resizing: The standard library could be packaged so
that it could be made smaller or larger, or there could be different
sized standard libraries made with different Python releases.

So there are benefits to packaging the standard library which would be
useful, for reasons which would have no impact on the "batteries
included" aspect of Python.

Plus, if the standard library was packaged and releases were made on
PyPI (in addition to including them normally in the Python releases),
we *might* be able to use PyPI's commenting infrastructure on this
packages (~evil grin~).


_______________________________________________
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 13, 2009, 12:59 AM

Post #10 of 18 (1494 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
you were thinking wrong. If suppose this feature is introduced it doesn't
mean python will become batteries removed!
you can ship the python release with the 'standard library packages' already
installed.
so what we get here is batteries included and ability to be changed after it
is discharged! ;) users did not get this feature before. what we experience
now is like 'use and throw' not the batteries but the whole python
distribution (like torchlight/flashlight) itself.
also users might get the ability to include other batteries too.

also say for example some X company wants its own python distribution
(including the standard libraries).
they may have the standard libraries removed or another custom library on
top of it (forget performance here). Now if the standard libraries were
available as packages a new version may be installed and tested at no time.
but if they get it by every release, there comes the problem.

this not only makes things easier on both sides (releasing side and user
side) it also makes the whole system transparent.
even patches for standard libraries may be available as soon as a bug has
been found, but not with the current system as Kevin mentioned.

say for example we take an opensouce project, the linux kernel as example.(
dont compare kernel with python each work differently and both scales are
not equal) just think it was another opensource software. i can say mostly
where there linux there is python (not talking about windows,embedded etc,
both software go hand in hand, so i took it for comparison). if there is a
bug/security issue found on the linux the patches are available in
days/mostly by the end of next week. but for python it must take more time.
may be some backward incompatible issue also comes along with it(eg. py3)
then they have to wait for the dependencies being updated. i am only
comparing the packaging and distributing system here not the softwares.
althought the rate at which the kernel development is at a very high scale,
the system is stable. and that is how open source works. every body can have
look into everything. that is what makes open source software best. if it
were (libraries) released as packages, by the time i install the patch
package, i may also get the patch package of the dependency too.


--

Regards,
Sriram.


ubershmekel at gmail

Nov 13, 2009, 1:30 AM

Post #11 of 18 (1493 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
On Fri, Nov 13, 2009 at 9:35 AM, Kevin Teague <kevin [at] bud> wrote:
>
> It's also worth noting that there are three issues with respect to standard
> library packaging which are all orthologous:
>
>  * Packaging for metadata: The standard library could be packaged so that
> there is consistent metadata about the distributions which compromise the
> standard library (version, author, maintainer, etc). This could be useful so
> that it would be easier to see at a glance which packages changed between
> any two Python releases. For example, I have a script which compares two
> working sets of packages and generates a web page with a colour-coded list
> of differences between those two working sets, based on the size of the
> version number bump, e.g. major.medium.minor (doesn't work with packages
> which use odd version numbering schemes). I've used this to compare working
> sets between different Grok releases or Plone releases to help see where the
> activity or major API changes might be happening inside any given Zope-based
> release. However, this script only works on 80% of the code, the other 20%
> is in the standard library, which is currently a black-box.
>
>    Also, if PEP 376 is accepted, then the standard library will be
> inviolation of the stanard metadata for installed packages unless this
> happens.
>
>  * Packaging for release:  The standard library could be packaged so that
> releases happen on PyPI. This could be useful so that it's easier to consume
> newer versions of a package before those packages are included in the next
> Python release. It could also make Python upgrades easier, as you could
> hold-back packages which might otherwise break an application upon upgrade.
> I happened to find a bug in a standard library package today, and currently
> my option is to: Submit bug report to PyPI, wait for Python 2.7 release,
> then wait for Plone to update to Python 2.7. I'm looking at many years
> before this fix goes into my production application, so in the meantime I
> need to maintain a work-around for the bug as well account for the day when
> this bug is fixed. It makes a mess of the code. If it was possible to
> release this package on PyPI, this could reasonably happen in a few days or
> at worst a couple months. The setup.py for that package could be updated to
> require the newer version of the package, and the workaround could be
> removed from the code.
>
>  * Packaging for resizing: The standard library could be packaged so that it
> could be made smaller or larger, or there could be different sized standard
> libraries made with different Python releases.
>
> So there are benefits to packaging the standard library which would be
> useful, for reasons which would have no impact on the "batteries included"
> aspect of Python.
>
> Plus, if the standard library was packaged and releases were made on PyPI
> (in addition to including them normally in the Python releases), we *might*
> be able to use PyPI's commenting infrastructure on this packages (~evil
> grin~).
>
>
> _______________________________________________
> 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/ubershmekel%40gmail.com
>

I kinda like the idea that the only packages included in the python
trunk would be distribute and pip (maybe just svn:external). Upon
packaging python for distribution (by installer or by source) the
relevant batteries would be included. Moving packages in and out of
the standard library just becomes so standard.

But of course this really should be decided by the people who work
most with the trunk and as I understand
http://mail.python.org/pipermail/stdlib-sig/2009-September/000609.html
this discussion's already run its course.

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


masklinn at masklinn

Nov 13, 2009, 2:50 AM

Post #12 of 18 (1486 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
On 13 Nov 2009, at 11:36 , Anand Balachandran Pillai wrote:
> I think the recent postings on "CPAN for Python" in this list also stems
> from similar thoughts.
No. The CPAN for Python messages (in and out of the list) are about third-party packages and a better way to manage (and a better experience of installing) those.

Think Ruby, it has a significant stdlib (though not as extensive as Python's), but it also has gems (and the `gem` CLI util). Or Haskell, which also has a significant stdlib (GHC does anyway) but also has cabal and cabal-install.
_______________________________________________
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 13, 2009, 4:15 AM

Post #13 of 18 (1486 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
as people like to compare languages take ruby for example (i am confident
that there will be no flame war here ;) )

we have PyPI
they have RAA

we have ?
they have rubyforge

i am seeing the rubyforge site now on my other tab, i find

Communications (365 projects)
Database (245 projects)
Desktop Environment (80 projects)
Education (81 projects)
Games/Entertainment (225 projects)
Internet (1339 projects)
Multimedia (296 projects)
Office/Business (226 projects)
Other/Nonlisted Topic (82 projects)
Printing (23 projects)
Religion (7 projects)
Scientific/Engineering (278 projects)
Security (86 projects)
Sociology (16 projects)
Software Development (1164 projects)
System (548 projects)
Terminals (37 projects)
Text Editors (136 projects)

these are the ongoing library development. although they are small in number
but it is put very clear.

in python the only way i have found about the libraries we have is by using
the doc (docs is great at this).
but i find less/no details about standalone/libraries that are not part of
python stdlib. (google is great at this)

lets take RAA now,

By Category
Application
114 subcategories
553 projects
Documentation
14 subcategories
31 projects
Library
150 subcategories
1179 projects
Ports
8 subcategories
10 projects

* By Project(ALL): 286 subcategories, 1773 projects
* By Owner: 905 owners

first of all they can never ever beat python's record of packages.

its funny i found a ruby project in pypi. on further inspection [rython
0.0.1] a library module for coding in ruby inside python code
transparently... how awesome..! its happy to see that libraries already has
taken the add-on feature. sad to see libraries mixed up with software
packages (no one will find about the library amidst those 1000's of
software!

packaging libraries has some other advantages too, like accumulation of
ideas happen. what if i design a *library* and no one uses it? whats the
point in creating? but if i could upload that in pypi or something like
that, also one python core active developer has had a look in to that, and
might one day be integrated with the standard modules..!

the best thing for now i propose is that segregating libraries and
applications in pypi. if thats a first stage bring about an awesome library
for distribution of packages (already in progress). third is chunk the
standard library and start providing the packages. seems simple but already
the python community is waiting for a long time.

--
Regards,
Sriram.


naughtysriram at gmail

Nov 13, 2009, 4:33 AM

Post #14 of 18 (1482 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
http://pypi.python.org/pypi?%3Aaction=search&term=library&submit=search

this lists all the packages with the term 'library' in it.

--

Regards,
Sriram.


steve at pearwood

Nov 13, 2009, 5:14 AM

Post #15 of 18 (1484 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
On Fri, 13 Nov 2009 09:36:10 pm Anand Balachandran Pillai wrote:

> 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

So Python, the *language*, has to become a package management system as
well as a programming language?

No thank you.

At most, perhaps there could be a package management tool in the
standard library:

try:
import stuff
except ImportError:
import packman
found = packman.requires(stuff, '1.27')
if found:
import stuff
else:
fail()



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

I don't.

I think the std library could possibly be organised better, but just
because something isn't useful to me right now, doesn't mean it isn't
useful to someone, and may be useful to me tomorrow.



--
Steven D'Aprano
_______________________________________________
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, 5:27 AM

Post #16 of 18 (1483 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
On Fri, Nov 13, 2009 at 6:44 PM, Steven D'Aprano <steve [at] pearwood>wrote:

> On Fri, 13 Nov 2009 09:36:10 pm Anand Balachandran Pillai wrote:
>
> > 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
>
> So Python, the *language*, has to become a package management system as
> well as a programming language?
>
> No thank you.
>
> At most, perhaps there could be a package management tool in the
> standard library:
>
> try:
> import stuff
> except ImportError:
> import packman
> found = packman.requires(stuff, '1.27')
> if found:
> import stuff
> else:
> fail()
>
>
>
That was just a suggestion, don't take it literally. My intention
was something similar to the stuff you have written above.
It would be however useful to standardize the pkg manager
"packman" to something in the standard library however.


>
> > 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.
>
> I don't.
>
> I think the std library could possibly be organised better, but just
> because something isn't useful to me right now, doesn't mean it isn't
> useful to someone, and may be useful to me tomorrow.
>
>
>
Ah yes, the only problem is that for any updates/fixes to your
module, you need to wait for the language release which is not
very much an ideal situation IMHO. Especially now when we are
in discussions about end of life of 2.x etc...

W.r.t the original analogy, batteries v 1.1 are included with the torch
1.1,
but if you want battery upgrade to 1.2, you need to buy torch 1.2..


>
> --
> Steven D'Aprano
> _______________________________________________
> 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


naughtysriram at gmail

Nov 13, 2009, 6:18 AM

Post #17 of 18 (1483 views)
Permalink
standard libraries don't behave like standard 'libraries' [In reply to]
> 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.
>


sorry for posting the link in a lone post, i must have posted it with my
previous post, and the theme is how to make the standard libraries
state-of-the-art and i many feel it must be in py-dev as it is directly
connected with the development of python. As it required some comparison, i
compared pypi with the ruby's *rubyforge*. in fact what i found astonishing
is that there are a lot of libraries (3rd party) available in packaged
forms. which is a very good sign, the problem is there is no sorted out list
for libraries and software in pypi.

*rubyforge* is like a pypi for *libraries* (standard and 3rd party)

i guess some misplaced topics such as [Python-Dev] PyPI comments and
ratings, *really*? , [Python-Dev] PyPI front page
are also getting alarming responses in the py-dev list. including yours, ;)


As Anand says requiring a new update of battery v1.5 requires update of
python/flashlight which only occurs every release is the manin senario.

I would also like to add that what if a company doesn't need the batteries
that you give at the first place, they have developed their own batteries
and want to use them(or use some from the default with theit own), also
wants to use the same flashlight/python system? - it would be *easy* only if
the batteries included had a feature of being removed.

--

Regards,
Sriram


regebro at gmail

Nov 21, 2009, 4:40 AM

Post #18 of 18 (1281 views)
Permalink
Re: standard libraries don't behave like standard 'libraries' [In reply to]
On Fri, Nov 13, 2009 at 09:59, Sriram Srinivasan
<naughtysriram [at] gmail> wrote:
> you were thinking wrong. If suppose this feature is introduced it doesn't
> mean python will become batteries removed!
> you can ship the python release with the 'standard library packages' already
> installed.
> so what we get here is batteries included and ability to be changed after it
> is discharged! ;)

You can. You can simply delete any files in the standard library that
you don't want.

What is your usecase?

--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
_______________________________________________
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

Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.