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
On Tue, Jun 18, 2019 at 10:57 AM Stephen J. Turnbull
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/VB4ETT... Code of Conduct: http://python.org/psf/codeofconduct/