Questions for lambda: in raises() (issue #2867)
Joachim Durchholz
The idea here is to have a lambda expression instead of a string.
I.e. instead of
>>> raises(TypeError, "Rational(2)*MyInt")
we want
>>> raises(TypeError, lambda: Rational(2)*MyInt)
This works very well, except when the code needs to test a statement
instead of an exception. I'd like to hear how to deal with these.
Here's the full list of remaining cases, grouped by constellation:
A) Testing nonassignability:
sympy/core/tests/test_assumptions.py, line 393:
raises(AttributeError, "x.is_real = False")
sympy/core/tests/test_containers.py, line 101:
raises(NotImplementedError, "d[5] = 6") # assert immutability
sympy/matrices/tests/test_matrices.py, line 1590:
raises(ValueError, "SparseMatrix([[1, 2], [3, 4]])[1, 2, 3] = 4")
B) Testing that a wrong import statement fails:
sympy/core/tests/test_numbers.py, line 538:
raises(ImportError, 'from sympy import Pi')
Comments? Ideas?
My thinking right now is:
A) Find or write a function that tests assignability.
C) I suspect this can't be wrapped in a function. If that single case is
all and there's no risk of ever having more test cases like this, I'd
find it acceptable to replace the raises() call with an explicit
try...catch sequence.
Regards,
Jo
Chris Smith
> Issue link: http://code.google.com/p/sympy/issues/detail?id=2867
>
> The idea here is to have a lambda expression instead of a string.
> I.e. instead of
>>>> raises(TypeError, "Rational(2)*MyInt")
> we want
>>>> raises(TypeError, lambda: Rational(2)*MyInt)
>
> This works very well, except when the code needs to test a statement instead
> of an exception. I'd like to hear how to deal with these.
>
> Here's the full list of remaining cases, grouped by constellation:
>
>
> A) Testing nonassignability:
>
> sympy/core/tests/test_assumptions.py, line 393:
> raises(AttributeError, "x.is_real = False")
>
> sympy/core/tests/test_containers.py, line 101:
> raises(NotImplementedError, "d[5] = 6") # assert immutability
>
Can't these be tested with hasattr:
>>> l=range(3);t=tuple(l)
>>> hasattr(l,'__setitem__')
True
>>> hasattr(t,'__setitem__')
False
> sympy/matrices/tests/test_matrices.py, line 1590:
> raises(ValueError, "SparseMatrix([[1, 2], [3, 4]])[1, 2, 3] = 4")
>
>
> B) Testing that a wrong import statement fails:
>
> sympy/core/tests/test_numbers.py, line 538:
> raises(ImportError, 'from sympy import Pi')
>
>
For these, can you redirect the output to an IO buffer, kind of like
capture in utilities does?
Since raises knows (via first arg) what error it is suppose to test,
maybe it could use different strategies for these cases.
Ronan Lamy
> Issue link: http://code.google.com/p/sympy/issues/detail?id=2867
>
> The idea here is to have a lambda expression instead of a string.
> I.e. instead of
> >>> raises(TypeError, "Rational(2)*MyInt")
> we want
> >>> raises(TypeError, lambda: Rational(2)*MyInt)
>
> This works very well, except when the code needs to test a statement
> instead of an exception. I'd like to hear how to deal with these.
As with most problems concerning the test suite, the best solution would
be to use pytest: [http://pytest.org/latest/builtin.html#pytest.raises].
Joachim Durchholz
> As with most problems concerning the test suite, the best solution would
> be to use pytest: [http://pytest.org/latest/builtin.html#pytest.raises].
How does it avoid the use of strings as parameters?
(Note that to use raises() as a context manager, we need to advance
Sympy's minimum requirement from Python 2.4 to Python 2.5.)
Sympy's pytest is, as far as I know, a fork of the "official" pytest.
Is reverting to "official" pytest a realistic option? I don't know what
changes were made to pytest, or why.
Joachim Durchholz
>> A) Testing nonassignability:
>>
>> sympy/core/tests/test_assumptions.py, line 393:
>> raises(AttributeError, "x.is_real = False")
>>
>> sympy/core/tests/test_containers.py, line 101:
>> raises(NotImplementedError, "d[5] = 6") # assert immutability
>>
>
> Can't these be tested with hasattr:
>
>>>> l=range(3);t=tuple(l)
>>>> hasattr(l,'__setitem__')
> True
>>>> hasattr(t,'__setitem__')
> False
If that's what these cases are supposed to test, I'm all fine.
>> sympy/matrices/tests/test_matrices.py, line 1590:
>> raises(ValueError, "SparseMatrix([[1, 2], [3, 4]])[1, 2, 3] = 4")
Hm. I now see that I didn't see before: the three tests raise different
exceptions, AttributeError, NotImplementedError, and ValueError.
I'm not sure how to deal with that, or whether it's a relevant
difference at all.
>> B) Testing that a wrong import statement fails:
>>
>> sympy/core/tests/test_numbers.py, line 538:
>> raises(ImportError, 'from sympy import Pi')
>>
>>
> For these, can you redirect the output to an IO buffer, kind of like
> capture in utilities does?
That would be possible, but simply rewriting the test as
try:
from sympy import Pi
okay = false
catch ImportError e
okay = True
if ! okay:
raise "importing Pi should have raised an ImportError"
sounds like less of a hassle. After all, there is just a single test of
this kind - unless there are going to be more of this type, anything
elaborate would probably be overkill.
> Since raises knows (via first arg) what error it is suppose to test,
> maybe it could use different strategies for these cases.
That decision can already be made by inspecting the type of the second
parameter: if it's callable, just call it inside a try...
Vladimir Perić
Alright, so is there any reason we can't move back to pytest now? I
know Aaron and Ondrej want to keep SymPy working in "pure" Python, but
development dependencies are fine and a normal users doesn't really
need to run tests. I also know you've been working on making us
compatible again, how is that progressing?
Aaron, Ondrej, what were the original reasons for moving away from
py.test and do they still apply?
>
> --
> 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+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Vladimir Perić
Vladimir Perić
> Am 26.11.2011 17:22, schrieb Ronan Lamy:
>>
>> As with most problems concerning the test suite, the best solution would
>> be to use pytest: [http://pytest.org/latest/builtin.html#pytest.raises].
>
> How does it avoid the use of strings as parameters?
> (Note that to use raises() as a context manager, we need to advance Sympy's
> minimum requirement from Python 2.4 to Python 2.5.)
I guess the point is that we don't need to reimplement things someone
already has (and pytest is used quite a bit).
Also, the minimum Python is 2.5 since after version 0.7.0 -- where did
you get the impression that we still support 2.4? That should probably
change, wherever it was written.
>
> Sympy's pytest is, as far as I know, a fork of the "official" pytest.
> Is reverting to "official" pytest a realistic option? I don't know what
> changes were made to pytest, or why.
>
Joachim Durchholz
> On Sat, Nov 26, 2011 at 5:48 PM, Joachim Durchholz<j...@durchholz.org> wrote:
>> Am 26.11.2011 17:22, schrieb Ronan Lamy:
>>>
>>> As with most problems concerning the test suite, the best solution would
>>> be to use pytest: [http://pytest.org/latest/builtin.html#pytest.raises].
>>
>> How does it avoid the use of strings as parameters?
>> (Note that to use raises() as a context manager, we need to advance Sympy's
>> minimum requirement from Python 2.4 to Python 2.5.)
>
> I guess the point is that we don't need to reimplement things someone
> already has (and pytest is used quite a bit).
I agree with that.
> Also, the minimum Python is 2.5 since after version 0.7.0 -- where did
> you get the impression that we still support 2.4? That should probably
> change, wherever it was written.
I picked that up from
http://code.google.com/p/sympy/wiki/DownloadInstallation?tm=2 .
Ronan Lamy
> On Sat, Nov 26, 2011 at 5:22 PM, Ronan Lamy <ronan...@gmail.com> wrote:
> > Le samedi 26 novembre 2011 à 14:06 +0100, Joachim Durchholz a écrit :
> >> Issue link: http://code.google.com/p/sympy/issues/detail?id=2867
> >>
> >> The idea here is to have a lambda expression instead of a string.
> >> I.e. instead of
> >> >>> raises(TypeError, "Rational(2)*MyInt")
> >> we want
> >> >>> raises(TypeError, lambda: Rational(2)*MyInt)
> >>
> >> This works very well, except when the code needs to test a statement
> >> instead of an exception. I'd like to hear how to deal with these.
> >
> > As with most problems concerning the test suite, the best solution would
> > be to use pytest: [http://pytest.org/latest/builtin.html#pytest.raises].
>
> Alright, so is there any reason we can't move back to pytest now? I
> know Aaron and Ondrej want to keep SymPy working in "pure" Python, but
> development dependencies are fine and a normal users doesn't really
> need to run tests. I also know you've been working on making us
> compatible again, how is that progressing?
Actually, it's usable already (I'll send a pull request soon) though not
quite ready to replace bin/test yet. As an example, running 'py.test
-rXs --durations=10 --pastebin=all sympy/' produces
http://paste.pocoo.org/show/512402
Aaron Meurer
> On Sat, Nov 26, 2011 at 5:22 PM, Ronan Lamy <ronan...@gmail.com> wrote:
>> Le samedi 26 novembre 2011 à 14:06 +0100, Joachim Durchholz a écrit :
>>> Issue link: http://code.google.com/p/sympy/issues/detail?id=2867
>>>
>>> The idea here is to have a lambda expression instead of a string.
>>> I.e. instead of
>>> >>> raises(TypeError, "Rational(2)*MyInt")
>>> we want
>>> >>> raises(TypeError, lambda: Rational(2)*MyInt)
>>>
>>> This works very well, except when the code needs to test a statement
>>> instead of an exception. I'd like to hear how to deal with these.
>>
>> As with most problems concerning the test suite, the best solution would
>> be to use pytest: [http://pytest.org/latest/builtin.html#pytest.raises].
>
> Alright, so is there any reason we can't move back to pytest now? I
> know Aaron and Ondrej want to keep SymPy working in "pure" Python, but
> development dependencies are fine and a normal users doesn't really
> need to run tests. I also know you've been working on making us
> compatible again, how is that progressing?
>
> Aaron, Ondrej, what were the original reasons for moving away from
> py.test and do they still apply?
I don't know. That happened before I joined the project. Ondrej,
Mateusz, or Vinzent might know.
Aaron Meurer
Aaron Meurer
Pages on the old wiki are very out of date. We should make sure that
they are also updated and not just moved whenever
http://www.google-melange.com/gci/task/view/google/gci2011/7132291 is
fixed.
Aaron Meurer
Aaron Meurer
> On Sat, Nov 26, 2011 at 12:54 PM, Vladimir Perić <vlada...@gmail.com> wrote:
>> On Sat, Nov 26, 2011 at 5:22 PM, Ronan Lamy <ronan...@gmail.com> wrote:
>>> Le samedi 26 novembre 2011 à 14:06 +0100, Joachim Durchholz a écrit :
>>>> Issue link: http://code.google.com/p/sympy/issues/detail?id=2867
>>>>
>>>> The idea here is to have a lambda expression instead of a string.
>>>> I.e. instead of
>>>> >>> raises(TypeError, "Rational(2)*MyInt")
>>>> we want
>>>> >>> raises(TypeError, lambda: Rational(2)*MyInt)
>>>>
>>>> This works very well, except when the code needs to test a statement
>>>> instead of an exception. I'd like to hear how to deal with these.
>>>
>>> As with most problems concerning the test suite, the best solution would
>>> be to use pytest: [http://pytest.org/latest/builtin.html#pytest.raises].
>>
>> Alright, so is there any reason we can't move back to pytest now? I
>> know Aaron and Ondrej want to keep SymPy working in "pure" Python, but
>> development dependencies are fine and a normal users doesn't really
>> need to run tests. I also know you've been working on making us
>> compatible again, how is that progressing?
>>
>> Aaron, Ondrej, what were the original reasons for moving away from
>> py.test and do they still apply?
>
> I don't know. That happened before I joined the project. Ondrej,
> Mateusz, or Vinzent might know.
>
> Aaron Meurer
By the way, I'm not opposed to it, as long as we don't lose any major
functionality.
Aaron Meurer
Joachim Durchholz
> On Sat, Nov 26, 2011 at 2:12 PM, Joachim Durchholz<j...@durchholz.org> wrote:
>> I picked that up from
>> http://code.google.com/p/sympy/wiki/DownloadInstallation?tm=2 .
>
> Pages on the old wiki are very out of date.
Uh-oh.
I reached that page from http://sympy.org -> Documentation ->
docs.sympy.org -> Installation -> Downloads.
Aaron Meurer
I think everything else on that page is more or less up-to-date (other
than listing old versions in the examples). We just forgot to update
the prerequisite there.
Really, though, that should be in our docs, not on the wiki. Then,
for example, the versions in the examples would always be up-to-date,
because I always do "git grep _current_version_" and change them all
before releasing.
Aaron Meurer
Aaron Meurer
Vinzent Steinberg
> > Aaron, Ondrej, what were the original reasons for moving away from
> > py.test and do they still apply?
>
> I don't know. That happened before I joined the project. Ondrej,
> Mateusz, or Vinzent might know.
IIRC we wanted to have a simple pure python test runner (py.test needs
(or needed, don't know if this still applies) compiled C code), that
can be bundled with sympy while keeping compatibility to py.test.
I think some features that py.test does not have got added later.
Silently we broke compatibility, so you get a lot of failing tests if
you run py.test now. (Mainly because @XFAIL does not work for it, but
not only this.) This is unfortunate, because py.test's output is much
nicer in case something goes wrong.
Vinzent