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. 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). 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. >>The only reference I can find is in PEP 290 and that merely >>reports this "fact". >> >>I'm -1 on deprecating apply(). Not only because it introduces yet >>another incompatiblity between Python versions, but also because it >>is still useful in the context of having a function which mimics >>a function call, e.g. for map() and other instance where you >>pass around functions as operators. > > Then maybe we should add something like operator.__call__. Why remove a common API and reinvent it somewhere else ? > OTOH, you're lucky that map isn't deprecated yet in favor of list > comprehensions; I expect that Python 3.0 won't have map or filter > either. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 05 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 50 days left
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