
On Thu, Jul 6, 2017 at 3:09 AM, Robert Collins <robertc@robertcollins.net> wrote:
On 1 July 2017 at 22:53, Nathaniel Smith <njs@pobox.com> wrote:
Hi all, .... If either hook is missing, or returns the built-in constant ``NotImplemented``. (Note that this is the object ``NotImplemented``, *not* the string ``"NotImplemented"``),
thank you for the clarification.
I am unclear why you *return* that rather than raising NotImplementedError ? NotImplementedError permits embedding details about the cause of the failure, whereas the singleton does not.
It seems to me cleaner - thinking in a type sense - to raise than to return a value from a different domain.
Basically the options I thought of are: - Create a dedicated exception type just for this, like: class PEP517OperationNotSupported(Exception). But... for technical reasons, there's no obvious way to define this class in such a way that the frontend and backend can both see it. There are some non-obvious approaches that could probably be made to work, but they're ugly and complicated and then we'd have to argue about them, and I don't want to do that. - Re-use one of the built-in exception types. But then, well, it's an existing exception type, which means that it already has some other use outside of our interface. And that means that if a backend happens to have this exception raised internally for some other reason, and doesn't catch the error, then it might bubble out to the frontend/backend interface and be misinterpreted. - Return a sentinel value. This avoids all the problems of the above solutions. There's also a solid precedent, since this is exactly how most __dunder__ methods work. For example, __eq__'s return type is "bool or NotImplemented", and NotImplemented means "do some kind of fallback or raise an error or whatever is contextually appropriate". int.__add__'s return type is "int or NotImplemented" and likewise. And it's true that exceptions allow an extra error message payload, but this is just an unstructured string and the only thing we can do with it is print it. So the backend can just as well print the message and then return NotImplemented. So I figured the last option was the best. Though it's not a huge distinction either way, given that NotImplementedError is sort of a weird holdover from before when ABCs were added and doesn't have real usage. -n -- Nathaniel J. Smith -- https://vorpus.org