variable declaration

Antoon Pardon apardon at forel.vub.ac.be
Mon Feb 7 08:55:35 EST 2005


Op 2005-02-07, Nick Coghlan schreef <ncoghlan at iinet.net.au>:
> Antoon Pardon wrote:
>> Op 2005-02-05, Nick Coghlan schreef <ncoghlan at iinet.net.au>:
>> 
>> 
>>>[ ... ]
>>>
>>>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



More information about the Python-list mailing list