With regard to | vs +, I honestly think the former would be *easier* for
beginners than the latter, because:
- Having a behavior that is unrelated to other uses of + would arguably be
harder to learn, or at least easier to misunderstand when you first see it.
- In the CS class world, many students will be covering sets anyway.
- | having related behavior across sets and dicts, which are themselves
related data structures, would make it easier to remember.
On Mon, Dec 2, 2019, 1:59 PM Guido van Rossum <gu...@python.org> wrote:
> 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/
>
_______________________________________________
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/3B3FZQBKIZI3IJARWIIE6RUBNCOKOANJ/
Code of Conduct: http://python.org/psf/codeofconduct/
