[Python-Dev] standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

>
> 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++. 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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

> 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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

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.
___
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/archive%40mail-archive.com

Re: [Python-Dev] standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

http://pypi.python.org/pypi?%3Aaction=search&term=library&submit=search

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

-- 

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/archive%40mail-archive.com

[Python-Dev] Fwd: standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

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.
___
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/archive%40mail-archive.com

[Python-Dev] standard libraries don't behave like standard 'libraries'

[Sriram Srinivasan]

> 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
___
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/archive%40mail-archive.com