What if hooks returned instances of the exception class? That way it doesn't bubble up from internal code, it can carry a message, and we can all agree that it's a semantically terrible idea that doesn't fit with any conventions. Even I'm not sure if this is a serious suggestion. ;-)
On Fri, Aug 25, 2017, at 08:31 PM, xoviat wrote: > Do you mean in addition to the two lines proposed here? I envision the > typical use case as attempting to do something that is required to > build an sdist deep inside the backend, discovering that it cannot be > done, and then raising the proposed exception. That's (other than the > two lines for the exception, which can put in Python later) shorter > than catching some custom exception in the hook and then returning > NotImplemented as a result. If you don't use exceptions, you'll > probably need to unwind the stack manually with return values.> > 2017-08-25 14:25 GMT-05:00 Donald Stufft <don...@stufft.io>: >> It's silly to require every backend to write code to guard against >> possible issues when we can structure the API to prevent those >> issues.>> >> Sent from my iPhone >> >> On Aug 25, 2017, at 3:04 PM, xoviat <xov...@gmail.com> wrote: >>> I agree with Nick that exceptions are the way to do things in Python >>> and with Donald that in general, Python's use of exceptions has >>> caused problems. But I don't think that this forum is the correct >>> place to discuss Python conventions, and so I would ordinarily say >>> that we should just accept that there will be problems and use the >>> NotImplementedError, assuming that "solution" doesn't cause a >>> firestorm that delays acceptance for a significant period of time. >>> The reasoning behind this is that Python has in general adopted this >>> approach (Nick is right that they would have used >>> NotImplementedError for binary operations except for performance >>> issues) even with its problems.>>> >>> However, another solution was dismissed without much thought: using >>> the "UnsupportedOperation" exception. We could for now simply >>> require an extra two lines in all backends:>>> >>> class DistutilsUnsupportedOperation(RuntimeError): >>> pass >>> >>> and then put UnsupportedOperation in the "distutils" library in 3.7, >>> with an eventual move to that. It's not pretty but there have been >>> plenty of hacks for backwards compatibility so far (it's rare to see >>> a project without some sort of compat.py file).>>> >>> 2017-08-25 13:34 GMT-05:00 Donald Stufft <don...@stufft.io>: >>>> The thing being bubbled up is a backend accidentally calling an API >>>> that has yet to be implemented (an error that should be reported) >>>> being bubbled up and erroneously handled as the backend reporting >>>> it doesn't support making a sdist (not an error, son no traceback).>>>> >>>> Sent from my iPhone >>>> >>>> >>>> > On Aug 25, 2017, at 2:23 PM, Paul Moore <p.f.mo...@gmail.com> >>>> > wrote:>>>> > >>>> > There's little or no opportunity here for letting exceptions >>>> > bubble up>>>> > to the user, or passing complex data back to the >>>> frontend. >>>> > Ultimately,>>>> > it's pretty much immaterial which form of reporting >>>> is used. >>>> > _________________________________________________ > 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
