>  And what I'm asking for is a justification for that.  Python in
> general has done fine without it for almost 3 decades.  I believe you
> that you have so far not found a way to make a pretty DSL without it,
> and similarly for Yanghao's HDL.  But it's far from obvious that none
> exists that most Pythonistas would find satisfactory.

I have found a way to make a pretty DSL, as I stated earlier in the thread I rewrite the AST.  From a user standpoint the problem is mostly moot.  From a developer standpoint rewriting the AST is an incredibly painful way to operate.

> So far the request for an in-place update operator seems to fail on
> both counts.  "Need" fails for lack of examples.  "Broad benefit"
> could be implied by "need" and a bit of imagination applied to
> concrete examples, but on the face of it seems unlikely because of the
> lack of persistent voices to date, and "need" itself hasn't been
> demonstrated.

Both Yanghao and I have provided examples, what precisely do you want in an example? Do you want my DSL code? Do you want the implementation of the AST rewriter?

As far broader impact a whole range of  common operations could be unified by an assign in place (stealing some form that thread)
context_var.set(val) # possibly the most glaring place in the standard library where an assign operator would be beautiful
lst[:] = new_list # while a common python idiom, this certainly isn't the most obvious syntax and only works on lists
dct.clear(); dct.update(new_dict) # to achieve the same thing as above with a dict or set.
numpy.copyto(array, new_array) # to achieve the same as above, note array[:] = new_array is an error

If we want to extend discussion beyond assign in place to be a write operator we can add to the list

Caleb Donovick

On Tue, Jun 18, 2019 at 3:43 PM nate lust <natelust@linux.com> wrote:
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):
    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
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VB4ETTBFY24ENOFHS2JJAAM7PGQD6COA/
Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SK2DFXFBG2YOIKNH3ZGO6HF422VC3Q5R/
Code of Conduct: http://python.org/psf/codeofconduct/