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 <brandtbuc...@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-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/W2FCSC3JDA7NUBXAVSTVCUDEGAKWWPTH/
> 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/VFQ2SJTHPEHOJUZSHMGA7GPI2M25N5J7/
Code of Conduct: http://python.org/psf/codeofconduct/
