Augument assignment versus regular assignment

[Antoon Pardon]

On 2006-07-17, Terry Reedy <tjreedy at udel.edu> wrote:
>  "Antoon Pardon" <apardon at forel.vub.ac.be> wrote in message
>  news:slrnebmhkp.tg1.apardon at rcpc42.vub.ac.be...
>> On 2006-07-15, Terry Reedy <tjreedy at udel.edu> wrote:
>>> The problem with understanding augmented assignment is that  it directs 
>>> the
>>> compiler and interpreter to do one or maybe two mostly invisible
>>> optimizations.  To me, the effective meaning of 'evalutating once versus
>>> twice' is most easily seen in the byte code generated by what is, 
>>> remember,
>>> the reference implementation.  What it does is what the
>>> less-than-super-clear doc means.
>>
>> But what does one do, if the question is raised whether or not the
>> code generated actually behaves as described by the language reference?
>
> One can just as well ask whether or not the docs actually describe the 
> behavior of the interpreter ;-).  In this case, not as well as one might 
> like.  Or, whether docs (and reasonable interpretation thereof) and 
> implementation match, which I claim they do it this case.

Well this dispute seems to boil down what is and what is not
involved in evaluating a target, and I have come to doubt that
target evaluation is even a meaningfull concept in python, so
maybe in order that I can understand how you come to that claim,
can you explain what a target evaluates to? So in a statement like

  col['t'] = exp

What is the evaluation of col['t']?

>> Shouldn't the language reference be clear enough to be understandable
>> without the help of byte code generated by the reference implementation?
>
> Normally, code experiments, such as you attempted, should be enough.  But, 
> as I said, trying to document mostly invisibly behavior is more difficult. 
> Based on looking at the byte code, I would put it this way: the difference 
> between assignment with duplicated source and target expressions and 
> augmented assigment with the same expression is that the interpreter 
> eliminates as much duplicate calculation as possible.  But precisely what 
> that mean seems a bit interpreter dependent to me.
>
> Should we expect a reference writen in (ambiguous) natural language to be 
> unambiguously clear?  I think not; that is why formal grammers and 
> notations were invented.  I learned Python with the doc in one window and 
> the interactive interpreter in another.

But there seems to be no formal system used for explaning the behaviour.
So I think one should take extra care in the language reference to
write in a way that is as clear as possible. IMO there is room for
improvement in the augmented assignment part. That is why I proposed
that the language reference would state that the primary of the
target would be evaluated only once, along with the index/key or slice.
Such wording avoids the notion of a target evaluation, which seems
trouble some and explains what kind of optimisations can be expected.

-- 
Antoon Pardon