<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 August 2017 at 10:28, Thomas Kluyver <span dir="ltr"><<a href="mailto:thomas@kluyver.me.uk" target="_blank">thomas@kluyver.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div><span><div>On Thu, Aug 24, 2017, at 02:21 PM, xoviat wrote:<br></div>
<blockquote type="cite"><div>I mean is this golang or Python? In Python, you raise notimplementederror.<br></div>
</blockquote><div><br></div>
</span><div>But there's a NotImplemented singleton in Python as well. The argument for using a return value is that the hook code has to deliberately return that, whereas a NotImplementedError could bubble up from some internal call, in which case it should really be registered as an error.<br></div>
</div></blockquote><div><br></div><div>This! And a backend that wanted a bubbled up NotImplementedError (or some other exception) to mean it actually doesn't support an operation, can catch the error and return. The ideal Pythonic way would be to raise a specific exception (something like PEP517UnsupportedOperation), but since it's not a builtin we would be left with the problem of defining it somewhere, which would become a dependency of all backends, and no, we don't want that.</div><div><br></div><div>All this has been hashed and rehashed before. I think we can move on from this argument and define `return NotImplemented` as the way to define a backend operation as unsupported.</div><div><br></div></div></div></div>