Andrew Barnert wrote: > Minor nit: the formatting is broken in some of the examples of candidates. The > first one I noticed is the last Sphinx one.
Thanks for spotting those! I'll fix them. > 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. I > don’t think > anyone wants both + and | meaning the same thing, or wants set operators > named +/&/^/- > instead of |/&/^/-. But this PEP argues compellingly for + over | if we’re > only adding > merge. So wouldn’t you want to finish both proposals and present them at the > same time, > with each one explicitly invalidating the other, rather than presenting this > one first > with the side effect of making the second one less compelling and/or more > complicated if > this one gets accepted? I'm the "interested author". I agree with you that this section (especially the parenthetical) could be worded better. It was included in the interest of summarizing discussions that had taken place, and at the time pipe-versus-plus was still being hotly debated. Had pipe won out (or if we change the PEP, not very likely at this point) I would have probably moved forward with the others. I have no interest in a competing PEP, or one that follows up with the other operators if +/+= is accepted. > Finally: if Mapping and MutableMapping don’t get the operators (if you’re > following > sequences, MutableSequence.__iadd__ exists but Sequence.__add__ doesn’t, I > think?), will > they be added manually to UserDict and ChainMap? (And are there any other > types that need > that question?) Open question. I think that's up to the authors of those individual non-subclasses, if so. `UserDict` is a bit different, as it has tests mandating that it have all of the same attributes as dicts. So, our C implementation gives `UserDict` the `__add__` trio, in the interest of having a passing test suite (clearly this is what the author intended, though). _______________________________________________ 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/GHGDXEHDBKXVKKKTHYO3RICBRDEVNMO4/ Code of Conduct: http://python.org/psf/codeofconduct/
