Author ncoghlan
Recipients The Compiler, cjw296, michael.foord, ncoghlan, pstch, yselivanov
Date 2016-08-21.06:44:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1471761857.68.0.366543720766.issue25532@psf.upfronthosting.co.za>
In-reply-to
Content
The infinite loop reported here is an inspect.signature bug - it's supposed to prevent infinite loops, but we didn't account for cases where "obj.__wrapped__" implicitly generates a fresh object every time.

unittest.mock.Mock is the only case of that in the standard library, but it's far from the only Python mocking library out there, and we should give a clear exception in such cases, rather than eating up all the memory on the machine.

This further means that while I agree the idea of blacklisting certain attributes from auto-generation in unittest.mock.Mock is a reasonable one, I also think you'll end up with a better design for *unittest.mock* by approaching that from the perspective of:

- having a way to prevent certain attributes being auto-generated is clearly useful (e.g. the "assert_*" methods, "__wrapped__")
- it's useful to have that default "blocked attribute" list be non-empty
- it may be useful to have that default list be configurable by tests and test frameworks without needing to update mock itself

That would make more sense as its own RFE, with a reference back to this bug as part of the motivation, rather than pursuing it as the *fix* for this bug.
History
Date User Action Args
2016-08-21 06:44:17ncoghlansetrecipients: + ncoghlan, cjw296, michael.foord, yselivanov, The Compiler, pstch
2016-08-21 06:44:17ncoghlansetmessageid: <1471761857.68.0.366543720766.issue25532@psf.upfronthosting.co.za>
2016-08-21 06:44:17ncoghlanlinkissue25532 messages
2016-08-21 06:44:17ncoghlancreate