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