On 07/10/2015 02:00 PM, Robert Collins wrote:
On 10 July 2015 at 23:34, Dmitry Tantsur <dtant...@redhat.com> wrote:
On 07/10/2015 01:13 PM, Robert Collins wrote:
I see that a lot of code started breaking due to
side_effect = Exception()
no longer working. Which was a declared way for some time, at least to my
best knowledge. And I do realize it's just a back port, but as a user of a
_library_ I'd like such breakages to be treated with care.
Maybe it happened and I was just not looking at a proper place.
Well, it works in the test suite, and it works by hand for me. So its
not as simple as 'oh look someone didn't care'.
Yeah, sorry. I'm happy to hear that it was not intentional.
from mock import Mock
m = Mock(side_effect=KeyError('foo'))
m()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "mock/mock.py", line 1055, in __call__
return _mock_self._mock_call(*args, **kwargs)
File "mock/mock.py", line 1111, in _mock_call
raise effect
KeyError: 'foo'
I accept that this is affecting Openstack, it sounds like the same
thing affecting Neutron and Nova, which turned out to be a bug in
autospec: try changing from 'autospec=True' to 'spec=True' [the nova
code didn't use set_spec=True, you may want/need to turn that off as
well]. Please capture any learnings to
https://github.com/testing-cabal/mock/issues/264
spec=True is not a complete replacement (does not seem to check method
signature) and is not documented to be used this way (well, at least I
didn't find it). But yeah, it kind of works.
2. side_effect syntax is no longer sane. Previously it was awesome:
side_effect = Exception()
side_effect = [value, Exception()]
etc. Now it's a big typing disaster:
side_effect = iter([Exception()])
ok, I can live with [], I understand that it may be required for some
corner
cases. I can't understand why mock can't call iter() internally.
And seriously, it's a breaking change, and should have been
communicated/issued a warning for some time.
It doesn't show up in the test suite - and I put specific code in
place to deal with the potentially related case where Python 2.7's
next() is different to the 3.x next() [2.6 didn't have next()]. So -
if you've found something that works in unittest.most on Python 3.6
[or 3.5beta3] then its a genuine backport bug and I can fix that up
asap. I haven't seen a bug filed from you about it, so perhaps thats
the first step.
People say it's stopped working in Python 3.4.2 and it did work in Python
3.4.0. I didn't verify this sentence.
So, if its stopped working in cPython, then we're going to want to
follow that (and bugfixes should go straight into cPython too). Once
its in 3.6 we can backport it very rapidly.
-Rob
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
