variable declaration

[Antoon Pardon]

Op 2005-02-08, Nick Coghlan schreef <ncoghlan at iinet.net.au>:
> Antoon Pardon wrote:ons already existing.
>> The compilor might generate a RESTORE instruction.
>
> Whether it is done as a LOAD/STORE or a RESTORE, it has to perform the same work 
> - check the name exists in the local namespace, and throw an exception if it 
> doesn't. If it the name does exist, perform a normal store operation.

It has to check if the name exists anyway. Because if it doesn't it has
to be created in the namespace directory and in the other case only
the value part has to be changed.

I have the impression you are looking at this too much from the view
of the current implementation where putting a an entry in
a directory is seen as an atomic operation.

So a possibility might be to augment dictionaries with a put method.
d.put(key, value) would throw an exception if the key wasn't already
in the dictionary but would otherwise behave as d[key] = value.

A STORE would then be implemented as a d[key] = value
A RESTORE would then be implemented as a d.put(key,value)

The latter wouldn't have to do more, it would just behave
different.

>>>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.
>
> STORE_FAST is set up to store a local as fast as is reasonably possible. The 
> space for the local is preallocated in the fast locals C array. How is an 
> instruction which does that *and something else* ever meant to be faster?

I don't know enough about pythons internals to answer here. Maybe you
have a point in this case, but you already stated that a RESTORE
would need more work then a STORE where IMO that was not the case,
so I'm not convinced the same kind of solution is not applicable here.

-- 
Antoon Pardon