A warning is just as good as an exception to our test runner (i.e., neither should be raised while running the tests). So option B is not really an option.
I don't really care what we do otherwise. raises() is private API, so we can do whatever we want with it. Aaron Meurer On Fri, Jun 1, 2012 at 2:12 AM, Joachim Durchholz <[email protected]> wrote: > Hi all, > > I recently had a pull request added that allows people to use > raises(ZeroDivisionError, lambda: 1/0) > instead of > raises(ZeroDivisionError, "1/0") > > The advantage is that it runs faster because the test code does not need a > separate compiler run, and code analysis tools can see what functions the > test code is using. > > I'm now thinking about what's the best was to establish the new usage. > Some strategies that I have thought of: > > A) Make strings in raises() calls a hard error. (This will ultimately go > away since upstream Pytest does not do that, and we'll eventually return to > testing the standard way.) > > B) Do not make it an error, just emit a warning. (Is this even doable? I > don't know if our Pytest has a mechanism for dealing with warnings.) > > C) Somebody do a periodic check for newly introduced raises() calls with > strings, fix them, and issue pull requests. > > I'll be doing C for now, but I won't be able to keep that up for an > indefinite amount of time. > What do people think? > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
