Adding more detailed exception types to numpy

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding more detailed exception types to numpy

Eric Wieser

PR #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.

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.

  • 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)

Eric


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Adding more detailed exception types to numpy

Stephan Hoyer-2
On Fri, Jan 4, 2019 at 8:18 AM Eric Wieser <[hidden email]> wrote:

PR #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.

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Adding more detailed exception types to numpy

Marten van Kerkwijk
Since numpy generally does not expose parts as modules, I think a separate namespace for the exceptions makes sense. I prefer `np.exceptions` over `np.errors`.

It might still make sense for that namespace to import from the different parts, i.e., also have `np.core.exceptions`, np.polynomial.exceptions`, etc., in part because the ones in `core` will have C helper functions. But that is a bit of an implementation detail.

-- Marten

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion