Official definition of call-by-value (Re: Finding the instance reference...)

[Terry Reedy]

Steven D'Aprano wrote:

>> Because of
>> Python's interpreted nature, names can't be compiled away as in C, they
>> need a concrete runtime existence, but does the language definition need
>> to assume that?
> 
> Of course. It wouldn't be Python if they didn't. However, remember that 
> objects don't have names.

Actually, Python pretty much does compile away names for function 
bodies.  (They are replaced by array indexes.)  It only needs to 
manifest them for locals().  CPython Dis.dis also accesses them, but 
that is obviously implementation specific.  I suspect that the names are 
stored as C char sequences rather than as Python string objects unless 
and until the latter are needed for locals().

...
>>>> class EqualsAll(object):
> ...     def __eq__(self, other):
> ...             return True
> ...
>>>> 5 == EqualsAll()
> True
> 
> 
> The methods of 5 don't even get called.

Why do you say that?  As I read the manual, type(left-operand).__eq__ is 
called first.

> This of course is a special case, because 5 is a built-in,

If true, this would be CPython-specific optimization, not language 
definition.

 > but in general, the result of x==y depends on  *both* x and y.

True.  But type(x) gets first crack at the answer.

...
> You're assuming that == compares values, which is often a safe 
> assumption, but not always.

The default is to compare by identity, so assuming otherwise is only 
safe when one knows the classes of x and y to over-ride the default.

Terry Jan Reedy