Op 2005-02-07, Nick Coghlan schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-02-05, Nick Coghlan schreef <[EMAIL PROTECTED]>: >> >> >>>[ ... ] >>> >>>With a rebinding operator, the intent of the last line can be made explicit: >>> >>>def collapse(iterable): >>> it = iter(iterable) >>> lastitem = it.next() >>> yield lastitem >>> for item in it: >>> if item != lastitem: >>> yield item >>> lastitem .= item >>> >>>(Note that doing this *will* slow the code down, though, since it has to >>>check >>>for the existence of the name before rebinding it) >> >> >> I think that most of the time it won't slow down the code as the >> checking will have been done during the compilation phase. It >> may even speed up code like this, because the compilation >> phase will have established that it is a rebinding and so >> code for testing whether a new variable is created or not >> is not necessarry here. >> > > Since unbound locals are generally detected at runtime rather than compile > time, > I see no real reason why this case would be any different. Static checks > would > be in the hands the tools like pychecker (as is currently the case for > references to unbound locals) > > Py> def f(): > ... x > ... x= 3 > ... > Py> f() > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File "<stdin>", line 2, in f > UnboundLocalError: local variable 'x' referenced before assignment > > So I'd expect the compiler to generate slower code for it (probably just a > LOAD/STORE pair instead of just a STORE instruction),
Why should we limit ourselves to instructions already existing. The compilor might generate a RESTORE instruction. > but the optimiser should > eventually be able to do something to eliminate the performance penalty due > to > the technically unnecessary LOAD. I doubt it will be able to beat a > STORE_FAST > when it comes to trying to get a performance improvement, though :) But maybe a RESTORE_FAST could. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
