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.
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
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.
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. **************************************************************************************
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.
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
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.
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
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@gmail.com | Brisbane, Australia ---------------------------------------------------------------
2009/11/12 Sriram Srinivasan <naughtysriram@gmail.com>:
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
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
On Thu, Nov 12, 2009 at 2:38 PM, "Martin v. Löwis" <martin@v.loewis.de> 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
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@v.loewis.de> 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~).
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.
On Fri, Nov 13, 2009 at 09:59, Sriram Srinivasan <naughtysriram@gmail.com> 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
On Fri, Nov 13, 2009 at 9:35 AM, Kevin Teague <kevin@bud.ca> 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@python.org 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
On Fri, Nov 13, 2009 at 1:08 AM, "Martin v. Löwis" <martin@v.loewis.de>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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/abpillai%40gmail.com
-- --Anand
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.
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.
http://pypi.python.org/pypi?%3Aaction=search&term=library&submit=search this lists all the packages with the term 'library' in it. -- Regards, Sriram.
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@gmail.com | Brisbane, Australia ---------------------------------------------------------------
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
On Fri, Nov 13, 2009 at 6:44 PM, Steven D'Aprano <steve@pearwood.info>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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/abpillai%40gmail.com
-- --Anand
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
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-distr... 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.
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
participants (15)
-
"Martin v. Löwis" -
Anand Balachandran Pillai -
Georg Brandl -
Greg Ewing -
Jesse Noller -
Kevin Teague -
Lennart Regebro -
Masklinn -
Matthew Wilkes -
Michael Foord -
Nick Coghlan -
Sriram Srinivasan -
Steven D'Aprano -
Ulrich Eckhardt -
Yuval Greenfield