[Distutils] PEP 517 again

[Thomas Kluyver]

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 <donald at 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 <xoviat at 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 <donald at 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.moore at 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 at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170825/b1ee1544/attachment.html>