On 2019-03-15 19:05, Jonathan Fine wrote:> Guido wrote:
There's been a lot of discussion about an operator to merge two
dicts. I participated in the beginning but quickly felt overwhelmed by the endless repetition, so I muted most of the threads.
But I have been thinking about the reason (some) people like
operators, and a discussion I had with my mentor Lambert Meertens over 30 years ago came to mind.
For mathematicians, operators are essential to how they think.
I agree about the endless repetition. I hope Steven D'A is making good progress with the revised PEP. I think that could help us focus discussion.
A few days ago, I drafted but did not send a post on binary operators. Prompted by Guido's helpful post, I'm appending it below. My approach and opinions are not the same as Guido's, but have much in common. Perhaps later, I'll clarify where I agree with Guido, and where my opinions differ.
Certainly, I think we have in common an emphasis on usability and in particular readability of code.
==================================================== SUBJECT: Naming things: would having more binary operators help?
SUMMARY I'm refocusing our earlier discussion on binary operators. I suggest we discuss the question: Providing more binary operators. When would this make naming things this easier? And when harder?
THE PROBLEM Naming things is hard.
For example https://hilton.org.uk/blog/why-naming-things-is-hard "Naming is communication. Bad names prevent code from clearly communicating its intent, which is why code with obfuscated names is spectacularly hard to understand. The compiler might not care, but the humans benefit from naming that communicates effectively."
AN EXAMPLE One person wrote: using + to merge dicts is simple, non-disruptive, and unlikely to really confuse anyone - so why not?
Another person proposed: d1 << d2 merges d2 into a copy of d1 and returns it, with keys from d2 overriding keys from d2.
A third person wrote: "|" (especially "|=") *is* suitable for "update" [So] reserve "+" for some alternative future commutative extension
[snip] There was also the suggestion of having both << and >>. Actually, now that dicts are ordered, that would provide a use-case, because you would then be able to choose which values were overwritten whilst maintaining the order of the dict on the LHS.