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" <don...@stufft.io> wrote: >> >>> On Aug 24, 2017, at 10:52 AM, Nick Coghlan <ncogh...@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
