On 12:14 pm, steve at 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. +1 Jean-Paul
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