[Distutils] PEP 517 again

[Thomas Kluyver]

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

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