[Distutils] A possible refactor/streamlining of PEP 517

[Nathaniel Smith]

On Thu, Jul 6, 2017 at 3:09 AM, Robert Collins
<robertc at robertcollins.net> wrote:
> On 1 July 2017 at 22:53, Nathaniel Smith <njs at 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