A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2012-November/122552.html below:

[Python-Dev] chained assignment weirdity

[Python-Dev] chained assignment weirdityChris Withers chris at simplistix.co.uk
Tue Nov 6 07:18:07 CET 2012
Hi All,

I bumped into this using Michael Foord's Mock library.
It feels like a bug to me, but thought I'd ask here before logging one 
in the tracker in case people know that we won't be able to fix it:

On 05/11/2012 13:43, Michael Foord wrote:
>
>>>>>> class Foo(object):
>>> ...  def __setattr__(s, k, v):
>>> ...   print k
>>> ...
>>>>>> f = Foo()
>>>>>>
>>>>>> f.g = f.x = 3
>>> g
>>> x
>>
>> Hmm, that's definitely counter-intuitive. Worth raising on python-dev?
>
> Well, I guess "it's always been that way", so changing it would be backwards incompatible. Feel free to raise it though. :-)

Here's the actual problem I had:

>>>>>>> mock = Mock()
>>>>>>> inst = mock.Popen.return_value = mock.Popen_instance = Mock(spec=Popen)
>>>
>>>
>>> Here the *return_value* is set first. So when mock.Popen_instance is assigned it already has a parent! (Setting a mock as the return value of another mock also establishes the child / parent relationship.)
>>>
>>> This is why calls to the instance are then not recorded in "method_calls".

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
             - http://www.simplistix.co.uk
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4