#13975: improve error reporting in some tests
------------------------------------+---------------------------------------
Reporter: cnassau | Owner: nthiery
Type: enhancement | Status: needs_work
Priority: minor | Milestone: sage-5.7
Component: categories | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers: Travis Scrimshaw
Authors: Christian Nassau | Merged in:
Dependencies: | Stopgaps:
------------------------------------+---------------------------------------
Comment (by nthiery):
Replying to [comment:6 cnassau]:
> I suggested this patch because it would have saved me a lot of time
recently. Now you're saying we can't have more helpful error messages
because
>
> {{{tester.assert_(self.prod([x]) == x)}}}
>
> is so much more readable than
>
> {{{tester.assertEqual(self.prod([x]),x,LazyFormat("self.prod([x]) !=
x for x=%s") % (x,))}}}
>
> Frankly, I find this un peu ridicule...
Sorry for being picky, but I handcrafted this piece of code with much
attention and a strong rationale (whether you agree or not with that
rationale is yours to decide). I have converged to this solution after
experimenting in practice with many other solutions for months.
Postmortem introspection with the debugger really is the way to
go. Having the element printed out isn't worth much in practice
because anyway the next thing you want to do is reproduce the
error. And 90% of the time recreating the elements from their string
output is just painful. Whereas with the debugger you can immediately
access the elements, run whatever calculation you need to , explore,
etc.
The rationale above assumes that someone encountering such errors is a
minimum of a dev. And we want devs to knows how to read a stack trace
and how to use the debugger.
That being said, I totally support efforts in the following
directions:
- Pointing people to the right tool
- Training people to the right tool
- Having the right tool work right (in particular having the debugger work
in the notebook)
I guess I can live, for the most used tests, with an idiom like:
{{{
tester.assert_( (x * y) * z == x * (y * z) ,
LazyFormat("(x*y)*z != x*(y*z) for (x,y,z) =
(%s,%s,%s)") % (x,y,z) )
}}}
to make the learning curve a bit smoother. Or even
{{{
tester.assertEqual( (x * y) * z, x * (y * z) ,
LazyFormat("(x*y)*z != x*(y*z) for (x,y,z) =
(%s,%s,%s)") % (x,y,z) )
}}}
But please make sure that the formula is *well highlighted*.
Legibility and conciseness is critical. For in the long run we want to
have such tests all over the Sage library. If there is not a concise,
legible, and uniform idiom, developers just won't write those tests.
If you want to see some non trivial examples where we simply can't
afford to put long Lazy format strings, see e.g.
sage.combinat.root_system.root_lattice_realizations.ParentMethods._test_root_lattice_realization.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13975#comment:7>
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
