Augument assignment versus regular assignment

[Antoon Pardon]

On 2006-07-18, Terry Reedy <tjreedy at udel.edu> wrote:
>
> "Antoon Pardon" <apardon at forel.vub.ac.be> wrote in message 
> news:slrnebpb99.tg1.apardon at rcpc42.vub.ac.be...
>> On 2006-07-17, Terry Reedy <tjreedy at udel.edu> wrote:
>>>  Or, whether docs (and reasonable interpretation thereof) and
>>> implementation match, which I claim they do it this case.
>
> The claim, in reference to the CPython implementation, that you refer to 
> below.
>
>> Well this dispute seems to boil down what is and what is not
>> involved in evaluating a target,
>
> Yes, and that is interpreter/implementation dependent.

Well I can agree that some things are implemantation dependent.
But shouldn't a language reference describe behaviour in terms or
implementation independent things?

>> and I have come to doubt that
>> target evaluation is even a meaningfull concept in python,
>
> Abstractly, it is whatever the interpreter does before it actually attaches 
> an object to the name or slot.  Again, the details are interpreter 
> dependent.

Well I can sort of agree with this. IMO there are two possible views
here, (not necessarily mutual exclusive) But if you agree with the first
IMO the language reference shouldn't make use of the concept to
describe behaviour.

  1) target evaluation is not a pythonic concept.

  2) It is whatever the interpreter does before it actually
     attaches an object, to a name/slot/... (in a primary).

>> so maybe in order that I can understand how you come to that claim,
>
> I looked at the CPython bytecode and saw that for augmented assigment, it 
> saved on the stack the internal information it needed for get and set 
> instead of recalculating it after the operation.  This is what I expected 
> and what I think the docs imply.
>
>> can you explain what a target evaluates to?
>
> The internal information the interpreter needs to do the assignment 
> (binding).

Yes but that seems to be an entirly internal interpreter affair. If
you stay at the level of the byte code, you will not find any opcode
that will result in or manipulate a target evaluation.

If you look at the language reference for the assignment, you will
not find the notion of a target evaluation mentioned there either.

That is because as far as I can see, an assignment is essentially
a ternary operation in python. An assignment needs a (name)space/scope,
an index/key/name and an object and those three are combined into
an assignment. Sometimes it looks like only two elements
are given, but that is because the space is implicit in cases
of a rebinding, (the STORE_GLOBAL and STORE_FAST opcode).

Talking about a target evaluation IMO only makes sense if
you view an assigment as a binary operation.

>> So in a statement like
>>  col['t'] = exp
>> What is the evaluation of col['t']?
>
> Try some personal introspection.  When you act as a Python interpreter, 
> what do you do?

I do the evaluation of the target in the __setitem__ method
(or the STORE_SUBSCR opcode).

Let as look what the compilor makes of it:
[blank lines added for clarity]

>>> dis(compile("col['t'] = exp", '', 'single'))

  1           0 LOAD_NAME                0 (exp)
              3 LOAD_NAME                1 (col)
              6 LOAD_CONST               0 ('t')

              9 STORE_SUBSCR        

The bytecodes at 0, 3 and 6 don't do any evaluation, they
just put things on the stack.

So what does the STORE_SUBSCR at location 9 do (or __setitem__)?

Well it will first do a number of preparations, like searching
for a bucket in a dictionary or a node in a tree or list, may
be even create one if a suitable wasn't available. And after
that is done, the object will be somehow attached.

So IMV those preparation before the attachment, belong to
whatever the interpreter does before it actually attaches
an object to a name/slot.

So the evaluation of the target is part of what is done by
STORE_SUBSCR or __setitem__.

Now you can object to the fact that I have divided the work
within an opcode. But if you do that, there seems to be
no place left to talk about a target evaluation in this
example.

So as a conclusion I would say one has two options:

  1) View target evaluations as not a pythonic concept

  2) Accept that target evaluation is done by STORE_SUBSCR/__setitem__

-- 
Antoon Pardon