> It's because Python doesn't actually have assignment to variables, it
> has binding to names.  So there's no "there" there to provide a
> definition of assignment.  In a class definition, the "local
> variables" are actually attributes of the class object.  That class
> object provides the "there", which in turn allows redefinition via a
> metaclass.

I understand this and while I would love to have metamodules and metafunctions to provide me a 'there' that is for another thread.

I don't really want to change the semantic of =.  What Yanghao and I are asking for is an in-place update/assign operator which isn't burdened with numeric meaning.

Caleb Donovick

On Thu, Jun 13, 2019 at 1:42 PM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Caleb Donovick writes:

 > In class bodies it is easy to redefine what assignment means, in
 > every other context its very annoying, I don't see why that must be
 > the case.

It's because Python doesn't actually have assignment to variables, it
has binding to names.  So there's no "there" there to provide a
definition of assignment.  In a class definition, the "local
variables" are actually attributes of the class object.  That class
object provides the "there", which in turn allows redefinition via a
metaclass.

Of course this doesn't *have* to be the case.  But in Python it is.
AFAICS making assignment user-definable would require the compiler to
be able to determine the type of the LHS in every assignment statement
in order to determine whether name binding is meant or the name refers
to an object which knows how to assign to itself.  I don't see how to
do that without giving up a lot of the properties that make Python
Python, such as duck-typing.

Steve