Last-second re changes don't appear to be going in the right direction <wink>: C:\Code\python\PCbuild>python ../lib/test/test_re.py Running re_tests test suite test_basic_re_sub (__main__.ReTests) ... ok test_constants (__main__.ReTests) ... ok test_escaped_re_sub (__main__.ReTests) ... ok test_flags (__main__.ReTests) ... ok test_limitations (__main__.ReTests) ... ERROR test_pickling (__main__.ReTests) ... ok test_qualified_re_split (__main__.ReTests) ... ok test_qualified_re_sub (__main__.ReTests) ... ok test_re_escape (__main__.ReTests) ... ok test_re_findall (__main__.ReTests) ... ok test_re_match (__main__.ReTests) ... ok test_re_split (__main__.ReTests) ... ok test_re_subn (__main__.ReTests) ... ok test_search_star_plus (__main__.ReTests) ... ok test_symbolic_refs (__main__.ReTests) ... ok ====================================================================== ERROR: test_limitations (__main__.ReTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "../lib/test/test_re.py", line 182, in test_limitations self.assertEqual(re.match('(x)*', 50000*'x').span(), (0, 50000)) File "C:\Code\python\lib\sre.py", line 132, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded ----------------------------------------------------------------------
On Thursday 24 April 2003 03:01 pm, Tim Peters wrote:
Last-second re changes don't appear to be going in the right direction <wink>:
C:\Code\python\PCbuild>python ../lib/test/test_re.py Running re_tests test suite test_basic_re_sub (__main__.ReTests) ... ok test_constants (__main__.ReTests) ... ok test_escaped_re_sub (__main__.ReTests) ... ok test_flags (__main__.ReTests) ... ok test_limitations (__main__.ReTests) ... ERROR test_pickling (__main__.ReTests) ... ok test_qualified_re_split (__main__.ReTests) ... ok test_qualified_re_sub (__main__.ReTests) ... ok test_re_escape (__main__.ReTests) ... ok test_re_findall (__main__.ReTests) ... ok test_re_match (__main__.ReTests) ... ok test_re_split (__main__.ReTests) ... ok test_re_subn (__main__.ReTests) ... ok test_search_star_plus (__main__.ReTests) ... ok test_symbolic_refs (__main__.ReTests) ... ok
====================================================================== ERROR: test_limitations (__main__.ReTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "../lib/test/test_re.py", line 182, in test_limitations self.assertEqual(re.match('(x)*', 50000*'x').span(), (0, 50000)) File "C:\Code\python\lib\sre.py", line 132, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded
Today's change to test_re (rather than a change to any of the sre code) is the problem. It appears the Skip was attempting to translate the tests to use the unittest module. One test (and perhaps others) were translated incorrectly. The original test was: try: verify(re.match('(x)*', 50000*'x').span() == (0, 50000)) except RuntimeError, v: print v Since this is *supposed* to cause a RuntimeError, it should be translated something like self.assertRaises(RuntimeError, re.match, '(x)*', 50000*'x') but definitely not as self.assertEqual(re.match('(x)*', 50000*'x').span(), (0, 50000)) Here's the CVS log entry: ---------------------------- revision 1.34 date: 2003/04/24 19:43:18; author: montanaro; state: Exp; lines: +294 -371 first cut at unittest version of re tests ---------------------------- Gary Herron
There's a bit more to this problem. It has to do with the *sre* test versus the *re* tests. When test_sre is run, it claims to run all its own tests as well as all of test_re. However any failed tests in test_re are not reported by test_sre. (Neither the one found by Tim nor any others I just purposely introduced into test_re.) This is clearly a problem with test_sre. Only if you run test_re directly rather than through test_sre do you see Tim's error. I'm hoping that Skip, who made these changes, can fix them. (BTW, I like the idea of putting all these tests into unittest -- the old test code looked like a cancer of multiple test methods grown on top of each other.) Gary Herron On Thursday 24 April 2003 03:38 pm, Gary Herron wrote:
On Thursday 24 April 2003 03:01 pm, Tim Peters wrote:
Last-second re changes don't appear to be going in the right direction <wink>:
C:\Code\python\PCbuild>python ../lib/test/test_re.py Running re_tests test suite test_basic_re_sub (__main__.ReTests) ... ok test_constants (__main__.ReTests) ... ok test_escaped_re_sub (__main__.ReTests) ... ok test_flags (__main__.ReTests) ... ok test_limitations (__main__.ReTests) ... ERROR test_pickling (__main__.ReTests) ... ok test_qualified_re_split (__main__.ReTests) ... ok test_qualified_re_sub (__main__.ReTests) ... ok test_re_escape (__main__.ReTests) ... ok test_re_findall (__main__.ReTests) ... ok test_re_match (__main__.ReTests) ... ok test_re_split (__main__.ReTests) ... ok test_re_subn (__main__.ReTests) ... ok test_search_star_plus (__main__.ReTests) ... ok test_symbolic_refs (__main__.ReTests) ... ok
====================================================================== ERROR: test_limitations (__main__.ReTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "../lib/test/test_re.py", line 182, in test_limitations self.assertEqual(re.match('(x)*', 50000*'x').span(), (0, 50000)) File "C:\Code\python\lib\sre.py", line 132, in match return _compile(pattern, flags).match(string) RuntimeError: maximum recursion limit exceeded
Today's change to test_re (rather than a change to any of the sre code) is the problem. It appears the Skip was attempting to translate the tests to use the unittest module. One test (and perhaps others) were translated incorrectly.
The original test was:
try: verify(re.match('(x)*', 50000*'x').span() == (0, 50000)) except RuntimeError, v: print v
Since this is *supposed* to cause a RuntimeError, it should be translated something like
self.assertRaises(RuntimeError, re.match, '(x)*', 50000*'x')
but definitely not as
self.assertEqual(re.match('(x)*', 50000*'x').span(), (0, 50000))
Here's the CVS log entry: ---------------------------- revision 1.34 date: 2003/04/24 19:43:18; author: montanaro; state: Exp; lines: +294 -371 first cut at unittest version of re tests ----------------------------
Gary Herron
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
On Thursday 24 April 2003 04:33 pm, Gary Herron wrote:
There's a bit more to this problem. It has to do with the *sre* test versus the *re* tests. When test_sre is run, it claims to run all its own tests as well as all of test_re. However any failed tests in test_re are not reported by test_sre. (Neither the one found by Tim nor any others I just purposely introduced into test_re.) This is clearly a problem with test_sre. Only if you run test_re directly rather than through test_sre do you see Tim's error.
Sigh... I find I was confused and must correct that last paragraph... Test test_sre imports re_test not test_re, and test_re also imports re_test -- perhaps you'll understand my confusion. Running test_sre should *not* find Tim's bug, but running test_re should. Test_sre has no problem, test_re needs to be fixed, and re_test, used by both, is fine. Sigh... Gary Herron
I think I understand the problem, and I've checked something in that makes the test pass, by insisting that the match raise RuntimeError with a specific error message. This is what was tested before; that particular error message was part of the expected output in Lib/test/output/test_re, which is now no longer needed and which I have hence deleted. (Hmm, I wonder if there are any other files in Lib/test/output that are no longer needed? All those files should eventually disappear...) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thursday 24 April 2003 06:51 pm, Guido van Rossum wrote:
I think I understand the problem, and I've checked something in that makes the test pass, by insisting that the match raise RuntimeError with a specific error message. This is what was tested before; that particular error message was part of the expected output in Lib/test/output/test_re, which is now no longer needed and which I have hence deleted.
Looks good. Perhaps test_re should be (or should have been) phased out. Test_sre makes many of the same tests (including today's offending one), as well as many new ones, and both run all the many old test from re_test. It must be a (historical) quirk that they both exist. It's mostly a waste to run both, and having two is a maintenance hassle, underscored by the fact that Skip has choosen the less important one of the two (IMHO) to modernize. It's not a high priority, but perhaps I'll look at straightening things out in the (somewhat distant) future. Gary Herron
Gary> It's mostly a waste to run both, and having two is a maintenance Gary> hassle, underscored by the fact that Skip has choosen the less Gary> important one of the two (IMHO) to modernize. I think it would be better to fold missing tests in from test_sre to test_re, not so much because I've partly converted test_re to use unittest, but because "re" is what people generally import. It never even occurred to me to look for "test_sre" when I was looking for a candidate test suite to convert to unittest. I'll keep working at completing the conversion. Skip
On Thursday 24 April 2003 08:05 pm, Skip Montanaro wrote:
Gary> It's mostly a waste to run both, and having two is a maintenance Gary> hassle, underscored by the fact that Skip has choosen the less Gary> important one of the two (IMHO) to modernize.
I think it would be better to fold missing tests in from test_sre to test_re, not so much because I've partly converted test_re to use unittest, but because "re" is what people generally import. It never even occurred to me to look for "test_sre" when I was looking for a candidate test suite to convert to unittest. I'll keep working at completing the conversion.
Sure. This is sensible. Gary Herron
Perhaps test_re should be (or should have been) phased out. Test_sre makes many of the same tests (including today's offending one), as well as many new ones, and both run all the many old test from re_test. It must be a (historical) quirk that they both exist. It's mostly a waste to run both, and having two is a maintenance hassle, underscored by the fact that Skip has choosen the less important one of the two (IMHO) to modernize.
It's not a high priority, but perhaps I'll look at straightening things out in the (somewhat distant) future.
Yes, this is mostly a historical artefact from the time when SRE was one of the two provided RE implementations. If you can straighten this one out, be my guest. I see no reason to stop working on the tests while Python is in beta. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
I think I understand the problem, and I've checked something in that makes the test pass, by insisting that the match raise RuntimeError with a specific error message. This is what was tested before; that particular error message was part of the expected output in Lib/test/output/test_re, which is now no longer needed and which I have hence deleted.
That's all exactly right. Thanks!
(Hmm, I wonder if there are any other files in Lib/test/output that are no longer needed? All those files should eventually disappear...)
Fred used to keep good track of this, so I doubt there's a big backlog. I expect the best candidates are those (like the re tests) recently converted to unittest. Getting rid of expected-output files should be part of such a conversion (or of a conversion to doctest). OTOH, the expected-output kind of test remains fine by me! It used to be very painful to see what went wrong when things failed, but quite some time ago that mechanism was reworked to save all the output and display a diff instead.
Tim> ====================================================================== Tim> ERROR: test_limitations (__main__.ReTests) Tim> ---------------------------------------------------------------------- Tim> Traceback (most recent call last): Tim> File "../lib/test/test_re.py", line 182, in test_limitations Tim> self.assertEqual(re.match('(x)*', 50000*'x').span(), (0, 50000)) Tim> File "C:\Code\python\lib\sre.py", line 132, in match Tim> return _compile(pattern, flags).match(string) Tim> RuntimeError: maximum recursion limit exceeded My apologies. I made most of these changes a couple months ago. test_re has been failing with the stack limit problem all this time. I thought it was related to the usual Mac OS X stack limit problem. Thanks to Guido and Gary also for elucidating and fixing the problem while I was at my son's hockey game. (I know, I'll get my priorities straight one of these days...) Skip
participants (5)
-
Gary Herron
-
Guido van Rossum
-
Skip Montanaro
-
Tim Peters
-
Tim Peters