> In order to keep the workaround code clean I'd suggest that the
> NotBrokenException should be raised in the broken() function, or
> maybe check_if_still_broken() ?
>
> if hasattr(foo, 'is_number) and foo.is_number:
> check_if_still_broken("Function.is_number")
> bar()
I like this idea. But what about the case where it's not the test that
is the problem, it's a procedure. e.g. when polys didn't handle
functions you had to factor out exp() by hand and that was several
lines of code. Using broken() I would do something like this:
if broken('assert factor(exp(2*x)+exp(x)==exp(x)*(1+exp(x))'):
eq = workaround_factor(eq)
else:
eq = factor(eq)
But maybe it would be better to feed broken() something that should be
true. In the previous example it would be better to feed the identical
expression to the two routines that you wish were equal:
if broken(work_around(exp(2*x)+exp(x)) == factor(exp(2*x)+exp(x)):
eq = workaround_factor(eq)
If it is something that raises an exception you could do this:
if broken(raises(AttributeError, "Function('f').is_foo") is not
None):
...
If it is something that simply gives the wrong result you could do
this:
if broken(Function("f").is_number is False):
...
A way that we could keep the code clean and have a clearing house for
issues is to import the test that fails
+---script
|
from issues import issue_1499
if issue_1499() and \
if hasattr(f, 'is_number') and f.is_number:
...
+---issues.py
|
def issue_1499():
""""Functions don't have an is_number attribute. etc....
""""
if Function('f').is_number is not False:
return True
else:
raise NotBrokenError
This is good because it is easy to see at a glance in issues.py what
issues are hindering the code. One can also write about the problem
and show what the workaround code should be instead. I just want a way
to make sure that the code gets changed (thus the actual execution of
issue_1499() for example). Perhaps the results of the issues could be
cached so the code doesn't always have to keep running the test.
On the other hand the idea of referencing could work like garbage
collection in python:
- when an issue is encountered, an xfail test is entered into
issues.py
- in the code, a comment marker is added, e.g.
if hasattr(f, 'is_number') and f.is_number: # issue_1499
- if the xfail test ever passes (and here's the garbage collection
phase) before someone
deletes the now-passing test, they search through the code for that
reference marker and make
the pertinent changes.
-> the con to this is that since it's only a comment there is no error
checking, e.g. if you typed issue1499 or issue_I499 you wouldn't find
this marker later.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sy...@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.
