[issue42556] unittest.mock.patch() cannot properly mock methods
New submission from Pierre Ossman : unittest.mock.patch() as it currently works cannot properly mock a method as it currently replaces it with something more mimicking a function. I.e. the descriptor magic that includes "self" isn't properly set up. In most cases this doesn't really matter, but there are a few use cases where this is important: 1. Calling base classes where you need to make sure it works regardless of super() or direct reference to the base class. 2. Multiple objects calling the same base class using super(). Without the self argument you can't tell the calls apart. 3. Setting up a side_effect that needs access to the object. In some cases you can pass the object using some side channel, but not all. E.g. not when mocking a base class' __init__(). (already reported as Issue35577). Right now you can work around this by using autospec, as that has the undocumented side-effect of properly setting up methods. So don't fix Issue41915 before this one or we lose that workaround. :) -- components: Library (Lib) messages: 382415 nosy: CendioOssman priority: normal severity: normal status: open title: unittest.mock.patch() cannot properly mock methods versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41915] unittest.mock.create_autospec(Obj, instance=True) has self keyword in _spec_signature if Obj implements __call__
Pierre Ossman added the comment: autospec's behaviour for methods is currently needed to work around Issue42556, so be careful with any fixes here so they don't break that workaround. -- nosy: +CendioOssman ___ Python tracker <https://bugs.python.org/issue41915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47259] string sorting often incorrect
New submission from Pierre Ossman : There is a big gotcha in Python that is easily overlooked and should at the very least be more prominently pointed out in the documentation. Sorting strings will produce results that is very confusing for humans. I happens to work for ASCII, but will generally produce bad results for other things as code points do not always follow the alphabetical order. The expressions chapter¹ mentions this fact, but you have to dig quite a bit to reach that. It also mentions that normalization is an issue, but it never mentions the issue about code point order versus alphabetical order. The sorting tutorial mentions under "Odds and ends"² that you need to use a special key or comparison function to get locale aware sorting. It doesn't mention that this also includes respecting alphabetical order, which might be overlooked unless you are very familiar with how the sorting works. The tutorial is also something you have to dig a bit to reach. Ideally string comparison would always be locale aware in a high level language such as Python. However, a smaller step would be a note on sorted()³ that extra care needs to be taken for strings as the default behaviour will produce unexpected results once your strings include anything outside the English alphabet. ¹ https://docs.python.org/3/reference/expressions.html ² https://docs.python.org/3/howto/sorting.html#odd-and-ends ³ https://docs.python.org/3/library/functions.html#sorted -- components: Interpreter Core messages: 416972 nosy: CendioOssman priority: normal severity: normal status: open title: string sorting often incorrect ___ Python tracker <https://bugs.python.org/issue47259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14474] mishandling of AttributeError in threads
New submission from Pierre Ossman : These three things do not mix: - AttributeError - Threads - Object methods An unhandled AttributeError thrown in a thread will not call sys.excepthook if the thread's start function is a class/object method. Test case: import sys import thread class Dummy: def worker(self): raise AttributeError thread.start_new_thread(Dummy().worker, ()) sys.stdin.readline() Note that you do not get a traceback here. Throwing any other exception type works fine, as does having worker() be a simple function. I think I've traced the issue to Objects/classobject.c:instance_repr(). It tries to look up the method, making sure to handle any AttributeError this might cause. But it fails to save and restore and Exception currently already active, effectively clearing out the current exception. -- components: Interpreter Core messages: 157350 nosy: ossman priority: normal severity: normal status: open title: mishandling of AttributeError in threads versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14474> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14476] sudo breaks python
New submission from Pierre Ossman : sudo breaks exception handling in Python in some subtle way. The following test program works fine when run directly, but breaks when run through sudo: #!/usr/bin/python import time def a(): try: while True: time.sleep(0.001) except KeyboardInterrupt: print "a" def b(): try: a() except KeyboardInterrupt: print "b" b() This is expected: pierre@pangolin:~$ ./test.py ^Ca But through sudo you get random behaviour: pierre@pangolin:~$ sudo ./test.py ^Ca b pierre@pangolin:~$ sudo ./test.py ^Ca b pierre@pangolin:~$ sudo ./test.py ^Ca b pierre@pangolin:~$ sudo ./test.py ^Ca pierre@pangolin:~$ sudo ./test.py ^Ca pierre@pangolin:~$ sudo ./test.py ^Cb Seen on Ubuntu 12.04 (alpha/beta) and on Fedora 16. Happens more often on Ubuntu though. -- components: Interpreter Core messages: 157358 nosy: ossman priority: normal severity: normal status: open title: sudo breaks python versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14476> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14474] mishandling of AttributeError in threads
Pierre Ossman added the comment: Indeed. I assume old style classes are still supported though? -- ___ Python tracker <http://bugs.python.org/issue14474> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14476] sudo breaks python
Pierre Ossman added the comment: Well that was fast. :) Sounds very much like the same bug I'm seeing here, yes. Unfortunately I'm not sure it's sufficient for us to rely on the distributions to update their sudo packages. A workaround would be preferable. I'll see if I can figure something out. Many thanks! -- ___ Python tracker <http://bugs.python.org/issue14476> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44185] mock_open file handle __exit__ does not call close
Change by Pierre Ossman : -- nosy: +CendioOssman ___ Python tracker <https://bugs.python.org/issue44185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44503] Hide __enter__ calls in mock_open
New submission from Pierre Ossman :
I'd like to write this test case:
with patch('builtins.open') as pyopen:
mock_open(pyopen, read_data="foo")
run()
pyopen.assert_has_calls([call("filename", "wt"),
call().write("gazonk"),
call().close()])
and I shouldn't have to care if the code is written like this:
def run():
f = open("filename", "wt")
try:
write("gazonk")
finally:
f.close()
or like this:
def run():
with open("filename", "wt") as f:
write("gazonk")
--
components: Library (Lib)
messages: 396469
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: Hide __enter__ calls in mock_open
type: enhancement
___
Python tracker
<https://bugs.python.org/issue44503>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44503] Hide __enter__ calls in mock_open
Pierre Ossman added the comment: Also see Issue44185 for __exit__. -- ___ Python tracker <https://bugs.python.org/issue44503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44052] patch object as argument should be explicit
New submission from Pierre Ossman :
Right now if you use unittest.mock.patch() as a decorator it may or may not
pass the object as an argument to the test function. The behaviour is a side
effect of the argument "new" rather than something the caller can explicitly
control.
In many cases this gives the desired behaviour, but not in all. So this
behaviour should be possible to explicitly controlled.
One common case is when using patch() as a class decorator. If you want to
avoid getting extra arguments to every test function, then "new" has to be
specified. But that means that it will be the same object that will be used for
every test, not a fresh one.
E.g.
@patch('foo.bar.baz', [])
class TestCases(unittest.TestCase):
def test_a(self):
...
def test_b(self):
...
def test_c(self):
...
The tests will now be running with the same list in "foo.bar.baz" rather than a
fresh empty list for each run. Ideally we could instead specify:
@patch('foo.bar.baz', new_callable=list, as_arg=False)
class TestCases(unittest.TestCase):
def test_a(self):
...
def test_b(self):
...
def test_c(self):
...
Or something along those lines.
--
components: Library (Lib)
messages: 393062
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: patch object as argument should be explicit
___
Python tracker
<https://bugs.python.org/issue44052>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44052] patch object as argument should be explicit
Pierre Ossman added the comment: I've always been cautious about running patch() manually since it was easy to miss the cleanup. But those fears might be irrelevant these days when we have addCleanup(). Still, decorators are a more robust in more complex setups since you don't have to worry about setUp() being properly called in every base class. So I still think this would be interesting. A different function might be an option to avoid adding arguments. Just like there are a few special patch.*() already. -- ___ Python tracker <https://bugs.python.org/issue44052> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
