[Distutils] PEP 517 again

[xoviat]

We could support both options on the frontend side. It's only a tiny bit of
duplication in pip.

On Aug 25, 2017 11:50 AM, "Thomas Kluyver" <thomas at kluyver.me.uk> wrote:

> Can I gently ask everyone involved to consider whether the
> notimplemented/error discussion is verging into bikeshedding (
> http://bikeshed.org/)?
>
> The technical arguments I have seen so far are:
> - The exception can include a message
> - The return value can't 'bubble up' from the internals of a hook like an
> exception
>
> I don't think the discussion of semantics is going to go anywhere: they
> are both reasonable ways for the backend to reply "sorry, Dave, I can't do
> that".
>
> On Fri, Aug 25, 2017, at 05:38 PM, xoviat wrote:
>
> 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
>
> *_______________________________________________*
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
> _______________________________________________
> 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/a264b7de/attachment-0001.html>