On Mon, Nov 28, 2011 at 11:14 PM, Steven D'Aprano <st...@pearwood.info> wrote: > Xavier Morel wrote: > >> Not being too eager to kill APIs is good, but giving rise to this kind of >> living-dead APIs is no better in my opinion, even more so since Python has >> lost one of the few tools it had to manage them (as DeprecationWarning was >> silenced by default). Both choices are harmful to users, but in the long >> run I do think zombie APIs are worse. > > I would much rather have my code relying on "zombie" APIs and keep working, > than to have that code suddenly stop working when the zombie is removed. > Working code should stay working. Unless the zombie is actively harmful, > what's the big deal if there is a newer, better way of doing something? If > it works, and if it's fast enough, why force people to "fix" it? > > It is a good thing that code or tutorials from Python 1.5 still (mostly) > work, even when there are newer, better ways of doing something. I see a lot > of newbies, and the frustration they suffer when they accidentally > (carelessly) try following 2.x instructions in Python3, or vice versa, is > great. It's bad enough (probably unavoidable) that this happens during a > major transition like 2 to 3, without it also happening during minor > releases. > > Unless there is a good reason to actively remove an API, it should stay as > long as possible. "I don't like this and it should go" is not a good reason, > nor is "but there's a better way you should use". When in doubt, please > don't break people's code.
This is a great argument. But people want to see new, bigger better things in the standard library, and the #1 reason cited against this is "we already have too much". I think that's where the issue lies: Either lots of cool nice stuff is added and supported (we all want our favourite things in the standard lib for this reason), and or the old stuff lingers... I'm sure a while ago there was mention of a "staging" area for inclusion in the standard library. This attracts interest, stabilization, and quality from potential modules for inclusion. Better yet, the existing standard library ownership is somehow detached from the CPython core, so that changes enabling easier customization to fit other implementations (jpython, pypy etc.) are possible. tl;dr old stuff blocks new hotness. make room or separate standard library concerns from cpython > > > > -- > Steven > _______________________________________________ > 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/anacrolix%40gmail.com > _______________________________________________ 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
