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
--
http://mail.python.org/mailman/listinfo/python-list
