A critic of Guido's blog on Python's lambda

[Alex Martelli]

<brian at sweetapp.com> wrote:
   ...
> > Being able to keep pass around state with functions is useful.
> 
> I agree and Python supports this. What is interesting is how
> counter-intuitive many programmers find this. For example, one of my

Funny: I have taught/mentored large number of people in Python, people
coming from all different levels along the axis of "previous knowledge
of programming in general", and closures are not among the issues where
I ever noticed large number of people having problems.

> So I try to use this sort of pattern sparingly because many programmers
> don't think of closures as a way of saving state. That might be because
> it is not possible to do so in most mainstream languages.

I don't normally frame it in terms of "saving" state, but rather of
"keeping some amount of state around" -- which means more or less the
same thing but may perhaps be easier to digest (just trying to see what
could explain the difference between my experience and yours).

> There are already some people in the Python community who think that
> Python has already gone too far in supporting "complex" language
> features and now imposes two steep a learning curve i.e. you now have
> to know a lot to be considered a Python expert. And there is a lot of
> resistance to adding features that will raise the bar even higher.

I might conditionally underwrite this, myself, but I guess my emphasis
is different from that of the real "paladins" of this thesis (such as
Mark Shuttleworth, who gave us all an earful about this when he
delivered a Keynote at Europython 2004).

I'm all for removing _redundant_ features, but I don't think of many
things on the paladins' hitlist as such -- closures, itertools, genexps,
etc, all look just fine to me (and I have a good track record of
teaching them...).  I _would_ love to push (for 3.0) further
simplifications, e.g., I do hate it that
    [ x for x in container if predicate(x) ]
is an exact synonym of the more legible
    list( x for x in container if predicate(x) )
and the proposed
    {1, 2, 3}
is an exact synonym of
    set((1, 2, 3))
just to focus on a couple of redundant syntax-sugar ideas (one in
today's Python but slated to remain in 3.0, one proposed for 3.0). It's
not really about there being anything deep or complex about this, but
each and every such redundancy _does_ "raise the bar" without any
commensurate return.  Ah well.


Alex