> > Yes, but part of the reason for this may be this very wart. I know > > I'm campaigning for this as a fix for what the OP calls the "read only > > lexical scoping gotcha". A fix for that makes it much more convienent > > to write closures that modify closed-over values, which in turn makes > > a much more compelling use case for using nested functions. > > Every use that does not involve shadowing variables can be handled with > a list indexing variant.
Yes, I know. Which is exactly why I described this change as a convenience. Just like programming in Python instead of machine language is a convenience. It's merely a matter of degree. > Is it ugly and a bit slower? Maybe. But no > one who really wants to use nested functions is (in my opinion) hurt by > Python's lack of the equivalent of 'outer' or the variant 'my'. All conveniences come at a cost; the operative question is whether the benefit outweighs the cost. For both the reason I cited above and the reasons you mention below, I think the answer is yes. Reasonable people can obviously disagree on this one. > > In any event, as you pointed out yourself, at last check Guido is +1 > > on this general idea. Maybe you should ask him why he's in favor of > > it :-) > > I'm only guessing here, but I would say it is because it removes a > (small) wart with regards to nested scopes, and it gets people to stop > complaining about this little thing (nevermind the functional > programming people who have been crying that Python ruins functional > programming for not having this included with the language). Yeah, I'm tired of people spreading the FUD that Python doesn't have proper closures. It does; they're just inconvenient to use. Hopefully Python 3000 will address this :-) Mike _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
