This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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.
History
Date User Action Args
2008-09-27 02:36:00benjamin.petersonsetrecipients: + benjamin.peterson, collinwinter, nedds
2008-09-27 02:35:59benjamin.petersonlinkissue3358 messages
2008-09-27 02:35:59benjamin.petersoncreate