[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091113/4e01e033/attachment-0001.htm>