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