On Mon, Aug 1, 2011 at 7:51 PM, Dhananjay Nene <[email protected]>wrote:
> On Mon, Aug 1, 2011 at 7:26 PM, Anand Balachandran Pillai > <[email protected]> wrote: > > IMHO, map/filter/reduce and the inevitable companion lambda were > > added on to Python when it was still trying to find its identity on > where > > it stood in the pantheon of dynamic typed languages - since it wanted > > to be everything for everyone it borrowed some of these constructs > > from Lisp or other functional languages. > > > > With addition of list comps, generators etc, these right now stand > > out like sore thumbs in the language and should be got ridden > > of at the earliest. > > I am certain there are contrary opinions, even though the BDFL has > weighed in. So yes, python is unlikely to be the playground for these > constructs. I find a degree of elegance and utility to these > constructs, though it is as well likely that these may seem like sore > thumbs to others. > I also used to think likewise when I first encountered these functions when I was playing around with Python many years back. However, I think the "elegancy" is actually a myth and is perhaps a pseudonym for being cryptic. For example, look at these competing solutions for summing the squares of first 10 integers. 1. List comp >>> sum([x*x for x in range(10)]) 285 2. Map >>> sum(map(lambda x: x*x, range(10))) 285 3. Reduce >>> reduce(lambda x,y: x + y*y, range(10)) 285 I dont think there will be much disagreement that the listing is also in the order of decreasing readability. The list comp solution is graspable at one look, the map one takes one step of mental computation and the reduce one takes a few mental hoops to jump through and is utterly confusing to anyone not familiar with list/functional programming. The reduce one is also very error prone. For example, a small mistake such as, >>> reduce(lambda x,y: x*x + y, range(10)) 2818129390158170901506703075470572449397357853477615482257305306043465L Produces a monstrosity instead of the expected answer. Perhaps those with a LISP/functional background find some mathematical elegance with these solutions. But from a pure Python perspective, they lack any elegance whatsoever. > > > Also, using any of the m/f/r trio with lambda is a performance killer. > > See an earlier post in a different thread for more on this. > > Its a performance killer only for cPython - its a function of runtime > not the construct. cPython is likely to stay a poorly performing > runtime for these. I do hope PyPy will fare much better - but that > remains to be seen. These constructs also help parallelisation (but > only when combined with immutability), and thats a feature python is > likely to be therefore unable to implement as far as I can imagine. Is > this a big deal - frankly no, since the sweet spot of python is pretty > broad. > _______________________________________________ > BangPypers mailing list > [email protected] > http://mail.python.org/mailman/listinfo/bangpypers > -- --Anand _______________________________________________ BangPypers mailing list [email protected] http://mail.python.org/mailman/listinfo/bangpypers
