On Fri, Jan 4, 2019 at 8:18 AM Eric Wieser <wieser.eric+numpy@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.

On Fri, Jan 4, 2019 at 8:18 AM Eric Wieser <wieser.eric+numpy@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.