[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> I really have troubles understanding the continual moans about lambda -- I
> don't think it's buggy (it was, before nested scopes) and I don't think adding
> lambda to the language was a mistake to start with either (whatever Guido's
> thoughts on the matter may be). In fact, I find python's lambda just about
> perfect -- maybe I'm missing something.
Okay, you make some good points. It's just a question of whether it
meets the 80/20 point. It may be that I overreact to the fact that it
doesn't seem "complete". But you're right that it can serve a purpose.
At the very least, the name of the operator is brain-dead. We might as
well add give functions meaningless names like "cdr" and "creat". ;)
> However if you want a function that contains more than one simple expression
> you can always (and presumably should) use def instead -- IMHO allowing
> lambdas that are are fully equivalent to defs would just lead to more
> spaghetti code, without adding any expressiveness to the language.
> .... Moreover
> overly complicated functions for which you can't come up with a name more
> likely than not are a sign of poor structure and potential code redundancy.
> Yes, I agree that for many cases comprehensions can be clearer, but I also
> think for many they aren't, notably when you've got more than one sequence:
> map(add, xs, ys)
> is, to me, better than:
> [x + y for (x,y) in zip(xs,ys)]
I think it's just a matter of which you learned first. zip is useful to
know for other contexts anyhow.
> in fact, as long I have a ready-made function, I'd prefer map:
> map(str, args)
Given that it exists, maybe. If we were creating the language from
scratch? I don't think so.
> Also, this style of programming naturally extends to lazy sequences (if you
> define things like, say xzipWith etc.), dictionaries and other scenarios that
> you can't accommodate with comprehensions or that are awkward and ugly with
> loops (e.g. reduce'ing).
Python will probably grow dictionary comprehensions and lazy
comprehensions when there is enough demand.
> clearer. Of course 'clear' also depends how used one is to a certain style of
> coding (e.g. do you find ``reduce(operator.getitem, pos, tree)`` clear? I
> certainly do).
I never use reduce, so no.
node = tree
for curpos in pos:
node = node[pos]
When I write code I always have in the back of my mind whether an
occasional Python programmer could follow it. I will use an advanced
feature if it dramatically simplifies the code. Otherwise, I will avoid
it. Few people would agree with me that that is worth spending effort
on. I happen to consider both "reduce" and "operator.getitem" advanced