[stdlib-sig] Breaking out the stdlib

[M.-A. Lemburg]

Orestis Markou wrote:
>> M.-A. Lemburg wrote:
>> Just to avoid any misunderstandings: I don't have anything
>> against argparse or adding it to the stdlib.
>>
>> I'm only concerned about the effects of deprecating modules
>> that are in wide-spread use, in this case getopt and optparse,
>> without providing a drop-in API compatible replacement.
> 
> A deprecated -> removed module can always exist in PyPI and manually
> installed (or perhaps they can live in their own special place
> stdlib-legacy). When a new version of Python comes out, people *do* have
> to spend some time testing their apps, so if something has moved from
> stdlib to stdlib-legacy, they can just install that in their site
> packages and go on pretending nothing happened.

True, but the modules in question mainly target small scripts,
not big applications. And those typically use the default Python
version found on the system via "#!/usr/bin/env python".

However, perhaps we can reach some middle-ground: we split out
LTS legacy modules into a stdlib-legacy or stdlib-compat
collection, keep applying patches to them as needed and
only apply the deprecation mechanism to the documentation
of these modules (the deprecation warnings tend to upset
consumers of the script's output and thus cause breakage on
their own).

That way, new code will likely start to be written against
the new modules, while old tested and working code can continue
to run with the old tested and working modules.

> For me, deprecating modules and adding new ones is more of a social move
> - it shows that the Python community cares, and it moves Python closer
> to the bleeding edge. I think it can be done without alienating legacy
> users.

I think points to one of the differences we are seeing in this
discussion:

One group of people wants bleeding edge, the other is more
interested in a stable code base.

IMHO, it's fair to ask the first group to put in a little more
effort and download whatever they want from PyPI, than putting
the burden on the second group.

After all, people who use bleeding edge code, need to be aware
of the fact that things can break, so it's better to make that
choice explicit, than have it made implicit for everyone.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 15 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/