Augument assignment versus regular assignment

[Terry Reedy]

 "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.

> 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.

> Otherwise the reference implemenation is being used as part of the
> language definition

Exactly.  People doing other implementations use it along with the docs.

> and then it can never be wrong.

No, 'part of' does not mean 'governing'.  A Python 'bug' is a discrepancy 
between doc and code.  Usually, normal experienced judgment is enough to 
decide which is faulty and needs to be changed.  Occasionaly, both are 
plausibly correct and such cases get referred to Guido or the developer's 
list for discussion and a decision.

Terry Jan Reedy