On Aug 28, 2017, at 3:59 PM, Thomas Kluyver <thomas@kluyver.me.uk> wrote:

The difference I see with the "return None" question is that there we
have an alternative (return NotImplemented) which is just as simple for
both sides, but avoids the identified issue with a buggy backend. The
only argument there seems to be for using None is about semantics - and
that's not a great argument, because 'practicality beats purity'.

With the questions over sdist/wheel consistency, there's a complexity
cost, for the spec and for frontends, in deciding that they can't. So
we're weighing a trade-off: do we force ourselves to resolve the
notimplemented question so that frontends can do sdist-wheel+fallback,
or do we leave it up to frontends and risk some bugs which we might
otherwise have prevented.


I think the best option is to just export an exception that a frontend can catch. That gives like 95% of the benefit of either mechanism for an extra 5% of work. If a backend is unwilling to add a:

class UnsupportedOperation(Exception):
    pass

To their backend, then they’re likely not a backend that we should be spending a whole lot of time or effort trying to support. Two copy/pasteable lines of code is a tiny price to pay. I haven’t talked to Nick, but I’d be surprised if he was against this, since it’s basically what he wanted with a more specific exception (which is good practice anyways).


Donald Stufft