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" <tho...@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" <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 > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
