"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 2006-07-15, Terry Reedy <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
