Raymond Hettinger wrote: >>BTW I definitely expect having to defend removing >>map/filter/reduce/lambda with a PEP; that's much more controversial >>because it's *removing* something and hence by definition breaking >>code. +1 on the PEP -1 on removing those tools - breaks too much code. > I suspect that lambda will be the only bone of contention. The reduce() > function can be moved to the functional module. The map() and filter() > functions are already covered by the itertools module. Nope. Think of the side-effects that can occur as a result of calling the function argument n times with different arguments. itertools only help if the functions don't have side-effects. Iteration is nice, but not the solution to everything :-) > Lambda will be more difficult. Eric Raymond adapted an anti-gun control > slogan and said "you can pry lambda out of my cold dead hands." A bunch > of folks will sorely miss the ability to create anonymous functions on > the fly. When lambda is used for deferred argument evaluation (a la PEP > 312), the def syntax is a crummy substitute. While I'm no fan of lambdas either, the removal would break too much code (e.g. I have 407 hits in the code base I use regularly alone). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2005) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
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