[Numpy-discussion] Adding more detailed exception types to numpy

[Stephan Hoyer]

On Fri, Jan 4, 2019 at 8:18 AM Eric Wieser <wieser.eric+numpy at gmail.com>
wrote:

> PR #12593 <https://github.com/numpy/numpy/pull/12593> adds a handful of
> new exception types for . Some consequences of this change are that:
>
>    1. The string formatting is moved to python, allowing us to give
>    better error messages without a lot of work
>    2. The formatting is dispatched lazily, meaning that users trying
>    ufuncs, but catching unsupported loop types don’t have to pay the cost of
>    string formatting
>    3. Users can catch a specific exception type. This might expose more
>    of our internals than we’re willing to though.
>    4. We need to expose these new exception names in the public API.
>
> Wonderful! This sounds great.


>
>
> 3 & 4 raise some questions, which I’d like some feedback on:
>
>    -
>
>    Should we actually expose the detailed exception types to the user, or
>    should they be kept an implementation detail? One way to hide the
>    implementation details would be
>
>    class TypeError(builtins.TypeError):
>        """actually UFuncCastingError"""
>    _UFuncCastingError = TypeError  # for internal use when raising
>    _UFuncCastingError.__module__ = None
>    class TypeError(builtins.TypeError):
>        """actually UFuncLoopError"""
>    _UFuncLoopError= TypeError  # for internal use when raising
>    _UFuncLoopError  .__module__ = None
>    del TypeError
>
>    This gives us all the advantages of 1 & 2 without the user noticing
>    that they’re receiving anything other than TypeError, which their
>    tracebacks will continue to show.
>
> I don't think this is a good idea -- think about how much confusion has
been caused by how NumPy gives scalars the same repr as Python builtins.
It's great to subclass TypeError for our needs, but we shouldn't add more
disguised subclasses of builtin Python types.

If we're really concerned about exposing too much API surface, we should
group these errors into logical groups inheriting from NumPy-specific
baseclasses, e.g., _UFuncCastingError and _UFuncLoopError could inherit
from UFuncError. Then at least users would at least know where to look (at
numpy.UFuncError) when their error doesn't serialize properly.

>
>    - If we do expose them, where should these exceptions go? In the past,
>    we also added AxisError and TooHardError - it would be nice to start
>    being consistent about where to expose these things
>    -
>       1. np.UFuncCastingError (expands the global namespace even further)
>       2. np.core._exceptions.UFuncCastingError (shouldn’t really be
>       private, since users won’t know how to catch it)
>       3. np.core.UFuncCastingError
>       4. np.core.umath.CastingError
>       5. A dedicated namespace for exceptions:
>          - np.errors.UFuncCastingError (matches pandas)
>          - np.exceptions.UFuncCastingError
>          - np.exc.UFuncCastingError (matches sqlalchemy)
>
> numpy.errors sounds like a good namespace to me. It's short and
descriptive. We can put aliases to AxisError and TooHardError in this
namespace, too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190104/4258eafa/attachment.html>