Create `np.exceptions` for new exceptions in NumPy?
Hi all, I want to add a new exception or two. It is a longer story, that you can find at the bottom :). Lets create a namespace for custom errors! I don't want to propose new exceptions that just get dumped in to the main namespace, so why not make one like `errors` in pandas or `exceptions` in scikit-learn. I would suggest introducing `np.exceptions`. We already have custom errors and warnings: * AxisError * TooHardError (used by `np.shares_memory()`) * ComplexWarning * RankWarning * VisibleDeprecationWarning * ModuleDeprecationWarning (not sure what this is) And a few private ones around ufunc "no loops" or casting failures (for delayed printing and formatting convenience). No need to move them all now, but maybe it is time to create a module where we put them all? With the intention that when the stars align, we will deprecate their main namespace aliases (either soon or in years). Beyond the error I just wanted, there were things brought up before, such as either `BroadcastError` or `ShapeMismatch`. Adding the namespace would make them more discoverable and just remove an annoying road-block for adding new ones. I will argue that the cost is practically zero. I do not want custom exceptions for too many things, but there are probably good reasons to have more than we do have right now, and even the ones we have seem enough for a namespace. Cheers, Sebastian The long story is that following one of those many threads, I decided that it looks worthwhile to introduce a new error class: InvalidPromotion I would want to use this for any/most promotion related failures. That means: * `np.result_type` or `np.promote_types` will give this if there is no valid way to promote * UFuncs will either give this error when there is no implementation or use it to raise a reliable error for "operation not defined for the inputs". [0] This would inherit from `TypeError` "of course". The why is a ball of yarn, that includes having a better shot at *finally* getting rid of the annoying comparison deprecation/future warning [1], eventually allowing more informative promotion errors, and that it might just be useful. Cheers, Sebastian [0] I first thought we should use the same error, but you can argue that `InvalidPromotion` doesn't include "this ufunc only works for floating point values". And yes, "no loop" can also mean "not implemented", but that may be need to be distinguished explicitly if really needed. [1] e.g. `np.array(["asdf"]) == 0`
Hi Sebastian, On Fri, Nov 11, 2022, at 05:46, Sebastian Berg wrote:
I would suggest introducing `np.exceptions`.
We already have custom errors and warnings:
* AxisError * TooHardError (used by `np.shares_memory()`) * ComplexWarning * RankWarning * VisibleDeprecationWarning * ModuleDeprecationWarning (not sure what this is)
At first glance, grouping these classes, mainly used internally, into a namespace makes sense to me. We also now have the ability to keep them exposed in their old locations for backward compatibility, while not showing them in __all__ and __dir__ (but not even sure that's 100% necessary?). Stéfan
No comment on the separate namespace for exceptions, but +1 to more
specific exceptions like BroadcastError or InvalidPromotion. They are
more informative, allow users to catch specific errors without pattern
matching the message string, and they would allow putting the relevant
error information in properties rather than just the message (e.g.,
like AxisError does with axis and ndim), which makes for nicer
programmatic access. It would be interesting to see this with
IndexError too, although I'm not sure if it's a good idea to change
the exception type there.
On Fri, Nov 11, 2022 at 11:10 AM Stefan van der Walt
Hi Sebastian,
On Fri, Nov 11, 2022, at 05:46, Sebastian Berg wrote:
I would suggest introducing `np.exceptions`.
We already have custom errors and warnings:
* AxisError * TooHardError (used by `np.shares_memory()`) * ComplexWarning * RankWarning * VisibleDeprecationWarning * ModuleDeprecationWarning (not sure what this is)
At first glance, grouping these classes, mainly used internally, into a namespace makes sense to me. We also now have the ability to keep them exposed in their old locations for backward compatibility, while not showing them in __all__ and __dir__ (but not even sure that's 100% necessary?).
The new exceptions wouldn't need to go there, but anyone who has ever wanted to catch one of the existing exceptions will have done "from numpy import AxisError" or "except np.AxisError". So I think they would need to stay, or at least go through a deprecation. I personally have written code that imports VisibleDeprecationWarning. Aaron Meurer
Stéfan _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: asmeurer@gmail.com
On Fri, Nov 11, 2022 at 2:47 PM Sebastian Berg
Hi all,
I want to add a new exception or two. It is a longer story, that you can find at the bottom :).
Lets create a namespace for custom errors! I don't want to propose new exceptions that just get dumped in to the main namespace, so why not make one like `errors` in pandas or `exceptions` in scikit-learn.
I would suggest introducing `np.exceptions`.
We already have custom errors and warnings:
* AxisError * TooHardError (used by `np.shares_memory()`) * ComplexWarning * RankWarning * VisibleDeprecationWarning * ModuleDeprecationWarning (not sure what this is)
And a few private ones around ufunc "no loops" or casting failures (for delayed printing and formatting convenience).
No need to move them all now, but maybe it is time to create a module where we put them all? With the intention that when the stars align, we will deprecate their main namespace aliases (either soon or in years).
Beyond the error I just wanted, there were things brought up before, such as either `BroadcastError` or `ShapeMismatch`. Adding the namespace would make them more discoverable and just remove an annoying road-block for adding new ones. I will argue that the cost is practically zero. I do not want custom exceptions for too many things, but there are probably good reasons to have more than we do have right now, and even the ones we have seem enough for a namespace.
This all sounds like a good idea to me, +1 Cheers, Ralf
On Fri, 2022-11-11 at 14:46 +0100, Sebastian Berg wrote:
Hi all,
I want to add a new exception or two. It is a longer story, that you can find at the bottom :).
Lets create a namespace for custom errors! I don't want to propose new exceptions that just get dumped in to the main namespace, so why not make one like `errors` in pandas or `exceptions` in scikit-learn.
I would suggest introducing `np.exceptions`.
Just a brief followup: The namespace exists on the main branch now, so adding new Exceptions will be easier. I want to add that exception specific to promotion failures [1]. With Marten we settled on: DTypePromotionError(TypeError) A follow-up to this might be something like a `DTypeError(TypeError)` as a superclass. Bike-sheds welcome! ;) We could even consider only having that superclass, that should be OK for my purposes. - Sebastian [1] I need this internally, because effectively when dtypes cannot promote we can be assume that their values are never equal. (e.g. strings and integers are always `!=` in Python, this helps NumPy to finally follow.)
We already have custom errors and warnings:
* AxisError * TooHardError (used by `np.shares_memory()`) * ComplexWarning * RankWarning * VisibleDeprecationWarning * ModuleDeprecationWarning (not sure what this is)
And a few private ones around ufunc "no loops" or casting failures (for delayed printing and formatting convenience).
No need to move them all now, but maybe it is time to create a module where we put them all? With the intention that when the stars align, we will deprecate their main namespace aliases (either soon or in years).
Beyond the error I just wanted, there were things brought up before, such as either `BroadcastError` or `ShapeMismatch`. Adding the namespace would make them more discoverable and just remove an annoying road-block for adding new ones. I will argue that the cost is practically zero. I do not want custom exceptions for too many things, but there are probably good reasons to have more than we do have right now, and even the ones we have seem enough for a namespace.
Cheers,
Sebastian
The long story is that following one of those many threads, I decided that it looks worthwhile to introduce a new error class:
InvalidPromotion
I would want to use this for any/most promotion related failures. That means:
* `np.result_type` or `np.promote_types` will give this if there is no valid way to promote
* UFuncs will either give this error when there is no implementation or use it to raise a reliable error for "operation not defined for the inputs". [0]
This would inherit from `TypeError` "of course". The why is a ball of yarn, that includes having a better shot at *finally* getting rid of the annoying comparison deprecation/future warning [1], eventually allowing more informative promotion errors, and that it might just be useful.
Cheers,
Sebastian
[0] I first thought we should use the same error, but you can argue that `InvalidPromotion` doesn't include "this ufunc only works for floating point values". And yes, "no loop" can also mean "not implemented", but that may be need to be distinguished explicitly if really needed.
[1] e.g. `np.array(["asdf"]) == 0`
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net
participants (4)
-
Aaron Meurer -
Ralf Gommers -
Sebastian Berg -
Stefan van der Walt