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/ _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
