A month ago I promised the Steering Council I'd review PEP 584 and promptly
got distracted by other things. But here it is, at last.
Some procedural things first: you (the PEP authors) should apply to the
Steering Council for a formal review. They most likely will assign one of
the SC members as a BDFL-Delegate who will guide the PEP to a resolution
(either acceptance or rejection, after any number of revisions). Don't wait
until you think the PEP is perfect! It doesn't have to be for a
BDFL-Delegate to be assigned.
Note that the SC elections have just started, and in a few weeks we'll have
a new SC. I won't be in it (I withdrew from the ballot). I don't know how
this will affect the chances of this PEP. (Also note that after an
election, a SC can overturn decisions by the previous SC, so I don't mean
this as a reason to hurry -- just something to consider.)
Now to the content of PEP 584.
## Should the operators be + and +=, or | and |= ?
I haven't read _all_ the posts on this topic, but I've seen quite a few,
and I still strongly favor | and |= . My reason for this is mainly that the
operation really does do a set union **on the keys**.
Also, + is already overloaded enough (numbers, strings, sequences) and we
don't need yet another, different meaning. The | operator should be known
to most users from sets (which are introduced before dicts in the official
Python tutorial).
I don't particularly care about learnability or discoverability in this
case -- I don't think beginners should be taught these operators as a major
tool in their toolbox (let them use .update()), and for anyone wondering
how to do something with a dict without access to the official docs,
there's always help(dict). The natural way of discovering these would be
through tutorials, reading of the library docs, or by reading other
people's code, not by trying random key combinations in the REPL.
## Does it matter that the operation is lossy, and not commutative in the
values?
Centithreads have been wasted on this topic, and I really don't care. I
**certainly** don't think that introducing a new operator or using a
different operator (<<, really?) is needed because of the operator's
asymmetry. A tutorial can show this in two or three lines, and anybody who
remembers these operators exists but has forgotten how they handle
conflicting values (and doesn't remember they correspond to.update()) can
type one line in the REPL to figure it out:
>>> {"a": 1} | {"a": 2}
{"a": 2}
>>>
## What about the Counter class?
The Counter class is an over-engineered contraption that has way too many
APIs to remember, and is quite inconsistent in what it tries to be. (When
does it delete zeros? Why does it sometimes discard negative values?) We
should not use it for guidance nor should we feel constrained by its design.
## What about performance?
Performance is not the only objective when using Python. Switching to
inplace operators (here |=) is a generally useful and well-known technique
(it also applies to string and list concatenation, for example).
## Other objections
The PEP does a good job of addressing pretty much everything that's been
brought up against it (in fact, perhaps it goes a little too far in
humoring obvious strawmen).
## Open questions
There's only one left in the PEP: "Should these operators be part of the
ABC Mapping API?"
No. This would require every Mapping implementation to add these. While you
might think that this could be addressed by adding concrete implementations
in the Mapping ABC, that doesn't work for |, since there's no API for
creating new instances.
It could be done for |=, by adding this to MutableMapping:
def __ior__(self, other):
self.update(other)
but without the ability to define __or__ in Mapping this seems
inconsistent. Mapping implementations are of course free to define __or__.
All in all I would recommend to the SC to go forward with this proposal,
targeting Python 3.9, assuming the operators are changed to | and |=, and
the PEP is brought more in line with the PEP editing guidelines from PEP 1
and PEP 12. (In particular, there are some suggested section headings there
that ought to be followed more closely. I'd be glad to give the authors
more guidance in this matter if they request it.)
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________
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/SWBLMTNQXNL3O5LN3327IYNPFIL2QSH5/
Code of Conduct: http://python.org/psf/codeofconduct/
