Message73916
| Author |
benjamin.peterson |
| Recipients |
benjamin.peterson, collinwinter, nedds |
| Date |
2008年09月27日.02:35:59 |
| SpamBayes Score |
5.939693e-15 |
| Marked as misclassified |
No |
| Message-id |
<1afaf6160809261935wd04836ep18b7ec7d653559a2@mail.gmail.com> |
| In-reply-to |
<1222482254.99.0.275762814977.issue3358@psf.upfronthosting.co.za> |
| Content |
On Fri, Sep 26, 2008 at 9:24 PM, Nick Edds <report@bugs.python.org> wrote:
>
> Nick Edds <nedds@uchicago.edu> added the comment:
>
> What do you think would be the best way to implement a test for this? To
> test it, I ran it on a known file that caused the old recursive method
> to fail, but I don't know if it makes sense to include that with the
> tests. I could always write a test to verify that the iterative element
> works, but as for testing the transition from recursive to iterative
> when the recursion limit is exceeded, do you think that is something I
> should do, and is there a better way than simply including the file that
> I know causes the recursion limit to be exceeded?
I recommend generating a deeply nested structure and/or using
sys.setrecursionlimit to make the recursion limit artificially low,
and testing that refactoring works as planned. |
|