Boris Borcic <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Armin Rigo wrote:
> > Hi,
> >
> > On Wed, Jun 07, 2006 at 02:07:48AM +0200, Thomas Wouters wrote:
> >> I just submitted http://python.org/sf/1501934 and assigned it to Neal so it
> >> doesn't get forgotten before 2.5 goes out ;) It seems Python 2.5 compiles
> >> the following code incorrectly:
> >
> > No, no, it's an underground move by Jeremy to allow assignment to
> > variables of enclosing scopes:
> ...
> > Credits to Samuele's evil side for the ideas. His non-evil side doesn't
> > agree, and neither does mine, of course :-)
> ...
> > More seriously, a function with a variable that is only written to as
> > the target of augmented assignments cannot possibly be something else
> > than a newcomer's mistake: the augmented assignments will always raise
> > UnboundLocalError.
>
> I am not really a newcomer to python. But lately I find myself regularly
> bitten
> by this compiler behavior that I tend to view as a (design) bug. This started
> happening after I saw that sets are just as good as lists performance-wise
> and I
> began changing code like this
I see your attempted use of a closure as a design bug in your code.
Remember that while closures can be quite convenient, there are other
methods to do precisely the same thing without needing to use nested
scopes. I find that it would be far easier (for the developers of
Python) and significantly more readable if it were implemented as a
class.
class solve:
def __init__(self, problem):
self.freebits = ...
...
def search(self, data):
...
self.freebits ^= swaps
...
...
Not everything needs to (or should) be a closure
- 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
