#12940: Combinatorial implementation of the affine symmetric group
---------------------------------------------------------+------------------
Reporter: sdenton | Owner: tom
denton
Type: enhancement | Status:
needs_work
Priority: minor | Milestone:
sage-5.11
Component: combinatorics | Resolution:
Keywords: affine, combinatorics, days38, days49 | Work issues:
Report Upstream: N/A | Reviewers:
Chris Berg, Anne Schilling
Authors: Tom Denton | Merged in:
Dependencies: #14673, #8392 | Stopgaps:
---------------------------------------------------------+------------------
Comment (by sdenton):
If this is the accepted usage of asserts vs ValueErrors in Sage, they
should be written up as such in the developer's guide; there wasn't any
way for me to know this was the local convention. Additionally, a
bug+patch should be made for the Cloneable Array class.
The line between internal assumptions and user input becomes very thin in
Sage, and this is an example of a very close case. The idea of the
Cloneable Array is that it's a simple data type with some extra
assumptions. When making a new one of these objects, you might break
those assumptions temporarily, but should end up with something that
satisfies the assumptions, and the 'check' methods are intended to check
that your methods have actually made this transformation effectively.
This is a machine use of the check method, but - as you say - the check
method also works well to check user input. After all, user input IS code
in Sage! It's not a bug in my code if buggy input fails to run. It's a
very, very different situation from taking user input from, say, a web
form and getting an Assertion Error. Users can run arbitrary code, so if
you want to avoid assertion errors at all cost, it should simply be
completely off-limits to use assert statements at all. I have, as a user,
definitely used statements like ``X._test_whatever()``, which, as you say,
are fine to have assert statements.
In short, if an assertion error happens in my code, yes, it's a bug in the
program. If one happens due to code that's been supplied by the user,
it's a bug in the user's input.
The only reason I can actually get behind to switch to ValueErrors is that
it's possible to turn off assertion errors at the Python level. But this
doesn't seem to be why you think they're as bad as segmentation faults....
In any case, I've refactored the code, and am attaching a new version of
the patch.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12940#comment:49>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
