
On Thu, Mar 21, 2019 at 06:02:05PM -0400, David Mertz wrote:
I dislike the symbol '+' to mean "dictionary merging with value updates." I have no objection to, and mildly support, adding '|' with this meaning.
It's not really possible to give "that one example" where + for meeting makes code less clear... In my eyes it would be EVERY such use.
I suspect that I may not have explained myself properly. Sorry. Let me try to explain again. A number of people including Antoine and Serhiy seem to have taken the position that merely adding dict.__add__ will make existing code using + harder to understand, as you will need to consider not just numeric addition and concatenation, but also merging, when reading code. *If this were true* it would be an excellent argument against using + for dict merges. But is it true? Would you agree that this example of + is perfectly clear today? for digit in digits: num = num*10 + digit By both the naming (digit, num) and presence of multiplication by the literal 10, it should be pretty obvious that this is probably doing integer addition. (I suppose it is conceivable that this is doing sequence repetition and concatenation, but given the names that interpretation would be rather unexpected.) We shouldn't find it hard to understand that code, using nothing more than *local* context. There's no need to search the global context to find out what num and digits are. (Although in the specific example I copied that snippet from, that information is only two or three lines away. But in principle, we might have needed to search an arbitrarily large code base to determine what they were.) Adding dict.__add__ isn't going to make that example harder to understand. If it did, that would be a big blow to the + proposal. Antoine and Serhiy seem to worry that there are existing uses of + which are currently easy to understand but will become less so if dict.__add__ is added. I respect that worry, even if I doubt that they are correct. If someone can demonstrate that their fear is well-founded, that would be an excellent counter-argument to the PEP's proposal to use +. What *doesn't* count as a demonstration: 1. Toy examples using generic names don't count. With generic, meaningless names, they're not meaningful now and so adding dict.__add__ won't make them *less* meaningful: # is this concatenation or numeric addition? who can tell? for spam in spammy_macspamface: eggs += spam Regardless of whether dicts support + or not, we would still have to search the global context to work out what eggs and spam are. Adding dict.__add__ doesn't make this harder. 2. Purely opinion-based subjective statements, since they basically boil down to "I don't like the use of + for dict merging." That point has been made, no need to keep beating that drum. 3. Arguments based on unfamiliarity to the new operator: preferences += {'EDITOR': 'ed', 'PAGESIZE': 'A4'} might give you a bit of a double-take the first time you see it, but it surely won't still be surprising you in five years time. I realise that this is a high bar to reach, but if somebody does reach it, and demonstrates that Antoine and Serhiy's fears are well-founded, that would be a very effective and convincing argument.
Every example presented in this thread or in the PEP feels wrong to me. I know about operator overloading and dunder methods and custom classes. My intuition about '+' from math, other programming languages, and Python, simply does not lead me to expect the proposed meaning.
And your subjective feeling is well-noted :-) -- Steven