Official definition of call-by-value (Re: Finding the instance reference...)
tjreedy at udel.edu
Mon Nov 17 05:34:58 CET 2008
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()
> The methods of 5 don't even get called.
Why do you say that? As I read the manual, type(left-operand).__eq__ is
> This of course is a special case, because 5 is a built-in,
If true, this would be CPython-specific optimization, not language
> 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
More information about the Python-list