<[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list