<div dir="auto">There's no need to return an instance of the exception class. As long as it is defined in the same name space as the hooks the front end will be able to access it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Aug 25, 2017 3:15 PM, "Thomas Kluyver" <<a href="mailto:thomas@kluyver.me.uk">thomas@kluyver.me.uk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div><div>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.<br></div>
<div><br></div>
<div>Even I'm not sure if this is a serious suggestion. ;-)<br></div>
<div><br></div>
<div><br></div>
<div>On Fri, Aug 25, 2017, at 08:31 PM, xoviat wrote:<br></div>
<blockquote type="cite"><div dir="ltr">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.<br></div>
<div><div><br></div>
<div><div>2017-08-25 14:25 GMT-05:00 Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span>:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div><div>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. <br></div>
<div><br></div>
<div>Sent from my iPhone<br></div>
</div>
<div><div><div><div><br></div>
<div>On Aug 25, 2017, at 3:04 PM, xoviat <<a href="mailto:xoviat@gmail.com" target="_blank">xoviat@gmail.com</a>> wrote:<br></div>
</div>
<blockquote type="cite"><div><div dir="ltr"><div>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.<br></div>
<div><br></div>
<div>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:<br></div>
<div><br></div>
<div>class DistutilsUnsupportedOperation(<wbr>RuntimeError):<br></div>
<div> pass<br></div>
<div><br></div>
<div>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).<br></div>
</div>
<div><div><br></div>
<div><div>2017-08-25 13:34 GMT-05:00 Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span>:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>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).<br></div>
<div> <br></div>
<div> Sent from my iPhone<br></div>
<div> <br></div>
<div><div><div><br></div>
<div>> On Aug 25, 2017, at 2:23 PM, Paul Moore <<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>> wrote:<br></div>
<div> ><br></div>
<div> > There's little or no opportunity here for letting exceptions bubble up<br></div>
<div> > to the user, or passing complex data back to the frontend. Ultimately,<br></div>
<div> > it's pretty much immaterial which form of reporting is used.<br></div>
<div> <br></div>
</div>
</div>
</blockquote></div>
</div>
</div>
</blockquote></div>
</div>
</div>
</blockquote></div>
</div>
<div><u>______________________________<wbr>_________________</u><br></div>
<div>Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br></div>
<div><a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a><br></div>
</blockquote><div><br></div>
</div>
<br>______________________________<wbr>_________________<br>
Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div></div>