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-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: sebast...@sipsolutions.net > _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
