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@stufft.io> wrote:

On Aug 24, 2017, at 10:52 AM, Nick Coghlan <ncoghlan@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@python.org

https://mail.python.org/mailman/listinfo/distutils-sig

_______________________________________________

Distutils-SIG maillist  -  Distutils-SIG@python.org

https://mail.python.org/mailman/listinfo/distutils-sig

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig