> Guido van Rossum wrote: > >>Could someone please explain why apply() was marked deprecated ? > > > > Becase it's more readable, more efficient, and more flexible to write > > f(x, y, *t) than apply(f, (x, y) + t). > > True, but it's in wide use out there, so it shouldn't go until > Python 3 is out the door. And it won't. But that doesn't mean we can't add a PendingDeprecation warning for it. > BTW, shouldn't these deprecations be listed in e.g PEP 4 ? > > There doesn't seem to be a single place to look for deprecated > features and APIs (PEP 4 only lists modules). That's a problem indeed. > I find it rather troublesome that deprecation seems to be using > stealth mode of operation in Python development -- discussions > about it rarely surface until someone complains about a warning > relating to it. There should be open discussions about whether > or not to deprecate functionality. I believe the discussions are open enough (things like this are never decided at PythonLabs, but always brought out on python-dev). But it's easy to miss these discussions, and the records aren't always clear. > > Then maybe we should add something like operator.__call__. > > Why remove a common API and reinvent it somewhere else ? To reflect its demoted status. --Guido van Rossum (home page: http://www.python.org/~guido/)
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