This is exactly the kind of discussion I came here for. Thanks.
Interestingly, this is probably still a bug in the python implementation. But let’s quickly improve the implementation a little. And this is only a superficial improvement. Can come up with much better implementations.
from types import MappingProxyType
orig = {1: 2}
mp = MappingProxyType(orig)
class MP:
def __getitem__(self, name):
return mp[name]
def __setitem__(self, name, value):
raise AttributeError()
proxy = MP()
class X:
def __eq__(self, other):
other[1] = 3
assert proxy[1] == 2
proxy == X() # AttributeError
Yes, there is a separate item specifically about C code execution in the original message.
Again, it seems to be about executing third-party C code. Its execution will have to be prohibited if security is needed only specifically for third-party python modules. We are talking about security only at the level of the python interpreter, which means that C code execution will have to be prohibited.
But can we still have an example where the bypass occurs only through python code?
It’s another matter if we come to the conclusion that python is thoroughly saturated with bugs and vulnerabilities. Is there really a lack of specific examples of problems here, so as not to give away how bad everything is with the internal implementation? 
But so far I have seen only one example of a bug specifically when executing python code. And it turned out to be quite fixable.
Are you familiar with its insides?
And I hope that we will have a lot more discussions in the same style 
By the way, here’s another thought. In fact, I’m acting as a python defender here. And everyone else seems to want to prove how bad python is and is teeming with problems.
Although it would seem that it should have been exactly the opposite.