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).