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.
--
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/archive%40mail-archive.com
