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.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~).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4