27.04.2011 23:09, Aaron S. Meurer пишет:
If so, how you imagine it in details?
As I understand the main task is: to handle warnings and inform about it
while testing.
If so then the SymPyDeprecationWarning, is one variant of realization of
this task.
As we have to handle warnings manually in any case (while testing), so
we can manage them without this auxiliary exception, because we can
direct supply info straitly to the report. And it is better, because we
can tune reporter specially how to deal with them.
Another question (which can be related with previous): whether to print
"DO NOT COMMIT" or not when warnings are raised?
I only mean that they should be turned into exceptions for the tests. Of
course, otherwise they should stay as warnings.
Aaron Meurer
On Apr 27, 2011, at 1:08 PM, Alexey U. Gudchenko wrote:
27.04.2011 22:22, Aaron S. Meurer пишет:
I already thought of much of this a while back. See
http://code.google.com/p/sympy/issues/detail?id=2142. We should
consider creating our own SymPyDeprecationWarning, since in Python
2.5+ DeprecationWarnings are not shown by default, but I think we
ought to enable them at least in isympy.
Also, we should run the tests with warnings turned into exceptions.
Testing warnings in doctests is a bad idea, I think. Just turn them
into exceptions and test them with raises().
Aaron Meurer
I something not understand why to turn warnings to exceptions is needed.
Suppose that I use SymPy as library. I don't what handle and catch the
insignificant exceptions to maintain my code to be always running.
--
Alexey U.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
