Conflation of NotImplemented and NotImplementedError #419
Comments
|
I have a fix for this, just waiting for #410 to be merged which adds the |
|
Some methods (mainly arithmetic ones?) also raise Eg. in CPython: >>> (12).__mul__('s')
NotImplementedRustPython: >>>>> (12).__mul__('s')
Traceback (most recent call last):
File <stdin>, line 0, in <module>
TypeError: Cannot multiply 'int' object and 'str' objector CPython: >>> (12).__divmod__('s')
NotImplementedRustPython: >>>>> (12).__divmod__('s')
Traceback (most recent call last):
File <stdin>, line 0, in <module>
TypeError: Cannot divmod power 'int' object and 'str' objectWhile some others just have implementation when they probably shouldn’t. Eg. comparing anything to CPython: >>> (12).__eq__('s')
NotImplementedRustPython: >>>>> (12).__eq__('s')
FalseThis makes it impossible to implement custom types that can be equal to built-in ones, eg. in CPython: >>> class Foo:
... def __init__(self, payload):
... self.payload = payload
... def __eq__(self, other):
... return self.payload == other
...
>>> Foo(3) == 3
True
>>> 3 == Foo(3)
True So there is going to be some work needed cleaning all the methods… |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
The contract for binary methods such as
__add__,__eq__, etc. is such that they are expected to returnNotImplementederror to signal lack of support for a particular type, in which case the interpreter will try flipping the operands, and finally fall back to object comparison (in the case of==).I believe that
VirtualMachine::call_or_unsupportedisRustPython's implementation of this behavior, but instead of using theNotImplementedbuilt-in constant, it expects implementors to raise aNotImplementedError. This can be seen by calling the magic methods directly:RustPython:
CPython:
This was discovered in #410.
The text was updated successfully, but these errors were encountered: