On Thu, Oct 17, 2019 at 12:41:29AM -0700, Andrew Barnert via Python-ideas wrote:
> Less trivial, but maybe dismissible: it says one of the authors is > going to write another PEP later to add the full complement of set > operators to dict. It says that one of the authors is *interested* in writing another PEP. https://www.python.org/dev/peps/pep-0584/#id28 That's not a promise to do so. And of course, if anyone else wishes to write that PEP first, please go ahead. > I don’t think anyone wants both + and | meaning the > same thing, or wants set operators named +/&/^/- instead of |/&/^/-. I think that is a fair point. The PEP points out that one advantage of the pipe operator is that it is forward-compatible with extensions to the API to support the full set of set operators. Some may consider that a *disadvantage* of the pipe operator. > But this PEP argues compellingly for + over | if we’re only adding > merge. Thank you. But as one of the authors, I'm not so certain that the argument for + over | is "compelling". Despite the PEP title, this is not *only* about the plus operator. I have tried my best to set out the best possible argument for the plus operator, but there are excellent arguments in favour of the pipe operator or a merged method as well, and I refuse to state my preference (or even whether or not I have a preference). The proposal has two conceptual parts: - the functionality - the spelling and of the two, I think the functionality is more important. When the discussion first started, the early consensus seemed to be in favour of plus; as the proposal continued, that consensus shifted, with more people stating that they wanted the functionality but hated the spelling. It may be that we cannot gain consensus over the correct spelling, and it will come down to a ruling from the Steering Council. There are at least four alternatives that the Steering Council can end up taking: - approval for the plus operator - approval of one of the alternatives - rejection of all of the alternatives - deferral Approval of one of the alternatives is not necessarily dependent on writing a competing PEP. I urge people to read the "Alternative Proposals" section https://www.python.org/dev/peps/pep-0584/#id9 and consider *all* the alternatives, not just give a blanket +1 or -1 to the PEP. -- Steven _______________________________________________ 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/SALGWKUFJNU6K6C2NRIWV2QYNPTT45A2/ Code of Conduct: http://python.org/psf/codeofconduct/
