I have been following this discussion for a long time, and coincidentally I recently started working on a project that could make use of assignment overloading. (As an aside it is a configuration system for a astronomical data analysis pipeline that makes heavy use of descriptors to work around historical decisions and backward compatibility). Our system makes use of nested chains of objects and descriptors and proxy object to manage where state is actually stored. The whole system could collapse down nicely if there were assignment overloading. However, this works OK most of the time, but sometimes at the end of the chain things can become quite complicated. I was new to this code base and tasked with making some additions to it, and wished for an assignment operator, but knew the data binding model of python was incompatible from p.

This got me thinking. I didnt actually need to overload assignment per-say, data binding could stay just how it was, but if there was a magic method that worked similar to how __get__ works for descriptors but would be called on any variable lookup (if the method was defined) it would allow for something akin to assignment. For example:

class Foo:
    def __init__(self):
        self.value = 6
        self.myself = weakref.ref(self)
    def important_work(self):
        print(self.value)
    def __get_self__(self):
        return self.myself
    def __setattr__(self, name, value):
        self.value = value

foo = Foo() # Create an instance
foo # The interpreter would return foo.myself
foo.value # The interpreter would return foo.myself.value
foo = 19 # The interpreter would run foo.myself = 6 which would invoke foo.__setattr__('myself', 19)

I am being naive is some way I am sure, possibly to how the interpreter could be made to do this chaining, but I figured I would weight in in case this message could spark some thought.

On Tue, Jun 18, 2019 at 5:41 AM Yanghao Hua <yanghao.py@gmail.com> wrote:
On Tue, Jun 18, 2019 at 10:57 AM Stephen J. Turnbull
<turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
> Maybe you'll persuade enough committers without examples.  Maybe the
> problem will be solved en passant if the "issubclass needs an
> operator" thread succeeds (I've already suggested to Yanghao offlist
> that Guido's suggested spelling of "<:" seems usable for "update",
> even though in that thread it's a comparison operator).  But both
> would require a lot of luck IMO.

I must have overlooked it ... <: seems good to me. I do agree with you
this needs more materialized evidence, I am working on it, in a few
areas more than just DSL/HDL.

For now I have abandoned my local change to cpython and settled with
list assignment signal[:] = thing. This in most case does not conflict
with numeric operations, nor list operations. (HDL signals are both
numbers and a list of individual signals). And it aligns with what it
means with the general python list.

Though, I am really looking forward to the success of <: operator as well ;-)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VB4ETTBFY24ENOFHS2JJAAM7PGQD6COA/
Code of Conduct: http://python.org/psf/codeofconduct/