Boris Borcic <[EMAIL PROTECTED]> wrote: > NB : That the compiler's interpretation has no use-cases is my crucial point, > it's the reason why I dared suggest a design bug - as you seem to take at > heart.
I think that Python's compiler with respect to augmented assignment and nested scopes is proper and sufficient. Believe whatever you want about my intentions. > Josiah Carlson wrote: > > and significantly more readable if it were implemented as a > > class. > > I'll deny that flatly since first of all the issue isn't limited to closures. > It > would apply just as well if it involved globals and top-level functions. > > > > > class solve: > > def __init__(self, problem): > > self.freebits = ... > > ... > > def search(self, data): > > ... > > self.freebits ^= swaps > > ... > > ... > > > > Not everything needs to (or should) be a closure > > Right. Let's thus consider > > freebits = ... > > def search(data) : > ... > freebits ^= swaps You seem to not realize that these different use-cases. Your new example involves a global variable that is *shared* among everyone that knows about this particular module. It also is repaired by a simple insertion of 'global freebits' at the beginning of the search function. The closure/class example is merely a method of encapsulating state, which I find easier to define, describe, and document than the closure version. Back in February, there was a discussion about allowing people to 'easily' access and modify variables defined in lexically nested scopes, but I believed then, as I believe now, that such attempted uses of closures are foolish when given classes. Given the *trivial* conversion of your closure example to a class, and my previous comments on closures "I find their use rarely, if ever, truely elegant, [...] more like kicking a puppy for barking: [...] there are usually better ways of dealing with the problem (don't kick puppies for barking and don't use closures).", you are not likely to find me agreeing with you about augmented assignment and/or lexically nested scopes. - Josiah _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com