> 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
```
coroutine.send(args)
process.communicate(args)
file.write(arg)
```
Caleb Donovick
On Tue, Jun 18, 2019 at 3:43 PM nate lust <natel...@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):
> 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...@gmail.com> wrote:
>
>> On Tue, Jun 18, 2019 at 10:57 AM Stephen J. Turnbull
>> <turnbull.stephen...@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-le...@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/
>>
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@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/SK2DFXFBG2YOIKNH3ZGO6HF422VC3Q5R/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/ZZX5C7JP4WNSTY4EM22C3T4H5KTOQHLU/
Code of Conduct: http://python.org/psf/codeofconduct/
