[issue21611] int() docstring - unclear what number is
Dmitry Andreychuk <and.dmi...@gmail.com> added the comment: I created this issue almost 4 years ago. Looking at it now, I think that I was asking too much of that docstring. I believe it's current version quite sufficient. I would close the issue, but I'm not sure if it's up to me to decide. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23661] Setting a exception side_effect on a mock from create_autospec does not work
Dmitry Andreychuk added the comment: python 3.4.3 is also affected. Is it possible to fix this in branch 3.4? -- nosy: +and versions: +Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21611] int() docstring - unclear what number is
Dmitry Andreychuk added the comment: Now I see that my message may look like a suggestion to add an encyclopedic definition of number there. Sorry. Actually I was talking about requirements for user-defined types to make them work with int(). Something like: If x has __int__() method return x.__int__(). Else x must be a string, bytes, or bytearray After reading the docstring I was like: Should I just define __int__() for my class to work with int() or maybe int() uses isintance() and my class has also to inherit from numbers.Number? But maybe It's just me and it's clear for everyone else. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21611 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21611] int() docstring - unclear what number is
New submission from Dmitry Andreychuk: https://docs.python.org/3.4/library/functions.html?highlight=int#int The docstring for int() function has these sentences: If x is a number, return x.__int__(). If x is not a number or if base is given... Unfortunately the docstring doesn't describe how the function decides if x is a number or not. After searching and experimenting I came to conclusion that it is the presence of x.__int__() method makes int() treat x as a number. But I'm not sure it's a precise requirement or just something that happens to work with current implementation. I think there should be a precise definition of what is considered to be a number there. -- assignee: docs@python components: Documentation messages: 219379 nosy: and, docs@python priority: normal severity: normal status: open title: int() docstring - unclear what number is versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21611 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21478] mock calls don't propagate to parent (autospec)
New submission from Dmitry Andreychuk: Calls to autospecced mock functions are not recorded to mock_calls list of parent mock. This only happens if autospec is used and the original object is a function. Example: import unittest.mock as mock def foo(): pass parent = mock.Mock() parent.child = mock.create_autospec(foo) parent.child() print(parent.mock_calls) Output: [] Expected output: [call.child()] It works fine if foo function is substituted with a class. Initially I came across this problem with patch() and attach_mock() but I simplified it for the demonstration. -- components: Library (Lib) messages: 218321 nosy: and priority: normal severity: normal status: open title: mock calls don't propagate to parent (autospec) type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21478 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
