Open Stack

On 07/10/2015 02:00 PM, Robert Collins wrote:
> On 10 July 2015 at 23:34, Dmitry Tantsur <dtantsur at 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
>
>