[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer
Hugo Geoffroy added the comment: I would like to point out that the changes in `ast.literal_eval` may have some security risk for code that do not expect this function to return an object with user-controlled length (for example, with `2**32*'X'`). AFAIK, this is not possible with the current version of `literal_eval`. At least [this library](https://pypi.python.org/pypi/serpent) would have a serious risk of remote DoS : > Because it only serializes literals and recreates the objects using > ast.literal_eval(), the serialized data is safe to transport to other > machines (over the network for instance) and de-serialize it there. Sorry for the noise if this is a useless/incorrect consideration. -- nosy: +pstch ___ Python tracker <http://bugs.python.org/issue11549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call
Hugo Geoffroy added the comment: This patch blacklists `__wrapped__` (using the same form as the first comment, with a more explicit exception message) in `unittest.mock._Call.__getattr__`. I also documented the change and added a tests that checks `assertFalse(hasattr(call, '__wrapped__'))`. I did not make the same change in the `Mock` class, as its instances are not usually set at module level (which is what triggers this bug in doctests, as they run `inspect.unwrap` on module attributes). I'd like to note that this regression can be nasty for some CI systems : it makes the Python interpreter infinitely allocate memory (as it's not a recursion error) and crashes any host that doesn't limit virtual memory allocation. -- keywords: +patch nosy: +pstch Added file: http://bugs.python.org/file44178/blacklist-wrapped-in-mock-call.patch ___ Python tracker <http://bugs.python.org/issue25532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call
Hugo Geoffroy added the comment: You are right, the fix would be better suited in `unwrap`. But, still, shouldn't any `__getattr__` implementation take care of not returning, for the `__wrapped__` attribute, a dynamic wrapper that provides the same attribute ? `__wrapped__` is commonly resolved to the innermost value without `__wrapped__`, which in this case never happens. This would also avoid problems with introspection tools that resolve `__wrapped__` without the help of `unwrap` (before Python 3.4 IIRC). -- ___ Python tracker <http://bugs.python.org/issue25532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25532] infinite loop when running inspect.unwrap over unittest.mock.call
Hugo Geoffroy added the comment: Another argument for having the fix in `unwrap` rather than `signature` is that this bug does not actually seem to be called by `signature`, as the doctest module calls `unwrap` for "inspect.isroutine(inspect.unwrap(val))". Also, this call does not even check for `ValueError`, which, if I'm not wrong, is something that should be corrected. Maybe `unwrap` could be made recursive to make it respect recursion limits directly ? Otherwise, limiting the loop seems like a good idea. (Temporarily, `from mock import call; call.__wrapped__ = None` seems to be a good workaround to prevent infinite memory allocation). -- ___ Python tracker <http://bugs.python.org/issue25532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
