[Distutils] PEP 517 again

Donald Stufft donald at stufft.io
Fri Aug 25 12:06:28 EDT 2017

> On Aug 24, 2017, at 10:52 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Aye, I do, and it should be "raise NotImplementedError('Explanation of
> the failed check')"
> Rationale:
> - Python isn't C or Go, so we indicate failures with exceptions, not
> error codes (NotImplemented is an necessary performance hack for
> operand coercion in tight loops, not an example to be emulated in
> other APIs)
> - allows the backend to provide information on what went wrong
> - means an unhandled backend error results in a traceback pointing to
> where the build failed, not some later point in the frontend code
> - if a backend developer is sufficiently worried about accidentally
> propagating NotImplementedError that they want to pretend they're not
> writing Python any more, they can use this idiom:
>    def public_hook_api(*args, **kwds):
>        try:
>            result, error_msg = _internal_hook_implementation(*args, **kwds)
>        except NotImplementedError as exc:
>            raise RuntimeError("Unexpected NotImplementedError") from exc
>        if result is NotImplemented:
>            raise NotImplementedError(error_msg)
>        return result
> That provides the backend with all the same assurances against
> accidentally letting NotImplementedError escape that a return code
> based public API would, without frontends even needing to be aware of
> the backend developer's aversion to reporting errors as exceptions.

I’m not really a fan of using NotImplementedError instead of NotImplemented. We’re not going to implement it by showing a traceback to where the NotImplementedError happened because it’s not an error case. And really that’s the important bit here, this is not an error case (as far as the API is concerned), this is just one of the possible return values that this function can produce. 

A front end may *choose* to make this an error case of course, but that is at a different layer than this API is operating.

It’s arguably not even the correct usage of NotImplementedError, since that is (and I quote from the Python docs): "In user defined base classes, abstract methods should raise this exception when they require derived classes to override the method, or while the class is being developed to indicate that the real implementation still needs to be added.”

This is not a case of some real implementation not having yet been added or some stub code getting called before it’s ready. This use case more closely resembles NotImplemented.

Donald Stufft

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170825/549269b7/attachment-0001.html>

More information about the Distutils-SIG mailing list