[Distutils] PEP 517 again

[xoviat]

According to the documentation, NotImplemented isn't appropriate either, as
is for binary operations only. There is no one value that's taylor made for
this situation, but an exception may be more appropriate as the underlying
cause is probably an error.

On Aug 25, 2017 11:11 AM, "Donald Stufft" <donald at stufft.io> wrote:

>
> 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
>
>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170825/d5453cb2/attachment.html>