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 ncoghlan
Recipients The Compiler, cjw296, michael.foord, ncoghlan, pstch, yselivanov
Date 2016-08-21.07:00:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1471762806.65.0.588703534849.issue25532@psf.upfronthosting.co.za>
In-reply-to
Content
My current inclination is that the right fix here is to have a hard limit in inspect.unwrap() itself, on the basis of "we won't eat all the memory on your machine, even when other code produces an infinite chain of distinct __wrapped__ attributes" is a guarantee that function should aim to be offering.

Since the limit is arbitrary anyway, sys.getrecursionlimit() seems like a reasonable choice. The current id-based checked then just becomes a way to bail out early if there's an actual cycle in the wrapper chain, with the hard limit only being reached in the case of introspection on recursively generated attributes.

Looking at the current inspect.signature and pydoc handling, inspect.signature lets the ValueError escape, while pydoc intercepts it and handles it as "no signature information available".

The inspect.signature case seems reasonable, but in pydoc, it may be worth trying inspect.signature a second time, only with "follow_wrapped=False" set in the call.

(I'm somewhat regretting raising ValueError rather than RecursionError for the infinite loop detection case, but I'm not sure it's worth the effort to change it at this point - the main benefit from doing so in 3.6 would be to better enable the "don't follow the wrapper chain when it's broken" fallback in pydoc)
History
Date User Action Args
2016-08-21 07:00:06ncoghlansetrecipients: + ncoghlan, cjw296, michael.foord, yselivanov, The Compiler, pstch
2016-08-21 07:00:06ncoghlansetmessageid: <1471762806.65.0.588703534849.issue25532@psf.upfronthosting.co.za>
2016-08-21 07:00:06ncoghlanlinkissue25532 messages
2016-08-21 07:00:06ncoghlancreate