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 vstinner
Recipients pitrou, python-dev, r.david.murray, serhiy.storchaka, vstinner
Date 2015-10-01.21:59:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1443736748.0.0.463261410017.issue25274@psf.upfronthosting.co.za>
In-reply-to
Content
> _Py_MakeEndRecCheck() was changed in issue5392 (noised Antoine as a committer).

Oh, I didn't know this issue. If I am right, it's a duplicate of this issue, even if it was a little bit different because the lower-water mark was computed differently.

> There are many ways to make it monotonic.

Since I don't understand well this issue, I prefer to keep the formula unchanged for low limit (smaller than 100, or smaller than 200 with my patch) to keep the 3/4 ratio.

> Since the formula is so complex, it would be worth to extract common part from _Py_MakeEndRecCheck() and sys_setrecursionlimit(). Otherwise the code can become desynchronized.

Right, it's now done in my new patch.

> The error message still looks confusing to me. May be short it to "limit is too low"? Noised David as grammar expert.

I prefer to really explain the fact that the RecursionError is raised depending on the current recursion depth. Otherwise, I'm quite sure that someone will complain that "too low" have different values on the same PC but on two different applications.

> Why not have an hardcoded minimum limit? Current recursion depth and therefore minimal recursion limit are implementation defined and can depend on a way how the module is executed (run a script, import a module, run with runpy or IDLE, etc).

I'm not sure that you understood correctly the issue. The root cause is that you cannot call sys.setrecursionlimit(X) at recursion depth Y. There is no constant "minimum limit": it depends on the recusion depth because of how Python handles recursion error (the overflowed flag).

An alternative would be to remove completly the overflowed flag with its fatal error. It was introduced during large refactoring of Python, maybe the bug cannot occur anymore?

Again, since I don't know the whole history of how Python handles recursion error, I prefer the conservative approach of changing the minimum amount of code.

> May be interpret the limit relatively to current recursion depth?

Hum, I dislike this idea. I prefer to keep an absolute value. Otherwise, it would make Python more surprising.
History
Date User Action Args
2015-10-01 21:59:08vstinnersetrecipients: + vstinner, pitrou, r.david.murray, python-dev, serhiy.storchaka
2015-10-01 21:59:08vstinnersetmessageid: <1443736748.0.0.463261410017.issue25274@psf.upfronthosting.co.za>
2015-10-01 21:59:07vstinnerlinkissue25274 messages
2015-10-01 21:59:07vstinnercreate