> 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.