Well, I can understand the lack of an update method... we don't want to update this, since it should be read-only.

My intent here was that the x |= y acts as if __ior__ wasn't defined, falling back to x = x | y (like a frozenset). The only difference is that it accepts an iterable of pairs, too... otherwise, I would just leave __ior__ undefined. It's also nice that both operators are pretty thin wrappers around the underlying mappings' implementations of those same operators.

But it's easy enough to change later, if we choose to raise now. I have a slight preference for the way I've written it up, but I'll let you make the call.

If we do raise here, what should the message be? I'd like to at least suggest trying |:

TypeError: |= is not supported by mappingproxy; assign from | instead

I really think that it's better to reject |= here -- everywhere else (touched by PEP 584) it mutates the object in place. I am not aware of use cases where this class is used other than protecting a class __dict__, and it just feels wrong to have a mutating operator.

I do realize this is a fine line, after all += for numbers and strings returns a copy while += for lists mutates in place. And frozenset has |= that returns a copy while set has |= that mutates. So if you want to ask advice from python-dev I would not object.

How about this error message:

TypeError: '|=' is not supported by mappingproxy; use '|' instead

So if you want to ask advice from python-dev I would not object.

No, you've made good points. I too suspect that this will hardly ever be used... and if enough people disagree, it's easy to change it later!

I want to assert that the return type is dict, which assertDictEqual enforces!

(as opposed to a new MappingProxy or something)

@gvanrossum: Please replace # with GH- in the commit message next time. Thanks!