Notes on new PEP: The section on {**d1, **d2} claims "It is only guaranteed to work if the keys are all strings. If the keys are not strings, it currently works in CPython, but it may not work with other implementations, or future versions of CPython[2]." That's 100% wrong. You're mixing up the unpacking generalizations for dict literals with the limitations on keyword arguments to functions. {**d1, **d2} is guaranteed to accept dicts with any keys, on any implementation of Python. I suspect you may actually be talking about the behavior of dict(d1, **d2), which behaved the way you described back in the Python 2 days, but that behavior has been long since disabled (in Python 3, if d2 keys are non-string, it immediately dies with a TypeError). Less critical, but still wrong, is the contention that "collections.Counter is a dict subclass that supports the + operator. There are no known examples of people having performance issues due to adding large numbers of Counters." A couple examples of Counter merge issues: https://bugs.python.org/issue36380 This is more about adding small Counters to large Counters (not a problem that would directly affect dict addition), regardless of the number of times you do it, but it gets *much* worse when combining many small Counters. https://stackoverflow.com/q/34407128/364696 Someone having the exact problem of "performance issues due to adding large numbers of Counters." On "lossiness", it says "Integer addition and concatenation are also lossy, in the sense of not being reversable: you cannot get back the two addends given only the sum. Two numbers add to give 356; what are the two numbers?" The argument in the original thread was that, for c = a + b, on all existing types in Python (modulo floating point imprecision issues), knowing any two of a, b, or c was enough to determine the value of the remaining variable; there were almost no cases (again, floating point terribleness excepted) in which there existed some value d != a for which d + b == c, where dict addition breaks that pattern, however arbitrary some people believe it to be. Only example I'm aware of where this is violated is collections.Counter, as addition strips zero values from the result, so Counter(a=0) and Counter() are equivalent in the end result of an add (which is not necessarily a good thing, see https://bugs.python.org/issue36380 , but we're stuck with it). Lastly, it seems a tad odd to deny that the Zen encourages "one way to do it" as if it were a calumny against Python invented by Perl folks (Perl folks take pride in TIMTOWTDI, but it always felt like a bit of pride in the perversity of it). Finely parsing the Zen to say it's only preferable, not a rule, is kinda missing the point of the Zen: None of it is prescriptive, it's a philosophy. Minimizing unnecessary "multiple ways to do it" to avoid kitchen sink syndrome is a reasonable goal. It's not an argument by itself if the new way to do it is strictly better, but pretending Python doesn't set a higher bar for features which already exist or are easily doable with existing tools is a little strange. Point is, if you're going to mention this in the PEP at all, justify this as something worth yet one more way to do it, don't argue that preferring one way to do it isn't a goal of Python. On Thu, Oct 17, 2019 at 5:35 AM Brandt Bucher <brandtbucher@gmail.com> wrote:
At long last, Steven D'Aprano and I have pushed a second draft of PEP 584 (dictionary addition):
https://www.python.org/dev/peps/pep-0584/
The accompanying reference implementation is on GitHub:
https://github.com/brandtbucher/cpython/tree/addiction
This new draft incorporates much of the feedback that we received during the first round of debate here on python-ideas. Most notably, the difference operators (-/-=) have been dropped from the proposal, and the implementations have been updated to use "new = self.copy(); new.update(other)" semantics, rather than "new = type(self)(); new.update(self); new.update(other)" as proposed before. It also includes more background information and summaries of major objections (with rebuttals).
Please let us know what you think – we'd love to hear any *new* feedback that hasn't yet been addressed in the PEP or the related discussions it links to! We plan on updating the PEP at least once more before review.
Thanks!
Brandt _______________________________________________ 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/W2FCSC... Code of Conduct: http://python.org/psf/codeofconduct/