We are about to ship
https://github.com/sagemath/sage/pull/37311
which adds a guide on choosing exceptions in sage context. Please come and
review.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
On Thursday, February 8, 2024 at 11:15:34 AM UTC+9 Kwankyu Lee wrote:
A method (or function) takes objects as input and computes an output. The
INPUT block defines coarsely the intended class of mathematical objects.
TypeError: the type (that can be checked by isinstance(obj, class)) of
On Friday, February 9, 2024 at 10:18:45 AM UTC+9 Travis Scrimshaw wrote:
I would be vague about a TypeError versus a ValueError. These are used in
various ways by different authors over different periods.
Helping an author in choosing the most appropriate one among sometimes
confusing array
The main relevance of classifying errors properly in python is for
try/except. Generally, a try/except should be tight both in code guarded
and in errors caught. An `except RuntimeError` is almost certainly a bad
idea. `except ZeroDivisionError` looks quite reasonable. `except
ValueError` or
You're misunderstanding what a catch-all means. It means *any* type (of
error) is reasonable. To put it mathematically, catch-all means union (of
sets), but the Python doc means difference (of sets).
An assertion is slightly different. It can (in principle) be turned off and
is just used for
Description of RunTimeError from docs.python.org: "Raised when an error is
detected that doesn’t fall in any of the other categories. The associated
value is a string indicating what precisely went wrong."
It is for exceptions that cannot be categorized, so I believe it is indeed
just a
On Thu, Feb 8, 2024 at 8:18 PM 'Travis Scrimshaw' via sage-devel <
sage-devel@googlegroups.com> wrote:
> For RuntimeError, I would make it sound like it tells you there is serious
> error occurring as it doesn't fall into any other error categories. This
> actually makes it the opposite of a
I would be vague about a TypeError versus a ValueError. These are used in
various ways by different authors over different periods. It can also be
very hard to make this rigorous. For example, for something accepting
integer inputs, then 2/2 fails the isinstance() check but shouldn't throw
an
A method (or function) takes objects as input and computes an output. The
INPUT block defines coarsely the intended class of mathematical objects.
TypeError: the type (that can be checked by isinstance(obj, class)) of the
input object does not belong to the intended class of mathematical
+1 from me on this specific case.
On the other hand, there are similar arbitrariness in other cases. So I
think there should be a broader discussion on what error should be raised
in what situation in mathematical context. This is what I think:
A method (or function) takes objects as input and
Dave, I agree that it is quite possible that not all of them are correct
non-invertible elements in a ring. Of course, we would go through an
examine them more individually as David suggested.
I was originally thinking ValueError as well, but, as Martin pointed out,
ArithmeticError is a bit
I agree that there are cases that shouldn't be changed to an
ArithmeticError, and that grepping for "invertible" isn't sufficient. But
I think with a narrower scope this change is a good idea: if the error
arises from attempting to invert a non-invertible element of a ring.
So +1 from me, with a
-1 from me.
Looking at just a few uncovered some that I think are definitely not
ArithmeticError.
Examples:
There is an occurrence of ValueError('{} is not invertible') in the
lift_isometry method of cliffordalgebra.py. Lifting an isometry is clearly not
an arithmetic operation.
Dear all,
currently, when trying to invert a non-invertible element, one of the
following errors is raised (found using `grep -r --include=*.{py,pyx}
--color -nH --null -e "Error(.*invertible" *`):
- 21 ValueError('{} is not invertible')
- 11 ZeroDivisionError("element is not
14 matches
Mail list logo
