search

derwiki-adroll / mock

Automatically exported from code.google.com/p/mock
BSD 2-Clause "Simplified" License
0 stars 0 forks source link

Feature Request: patch decorator should be able to use kwargs #46

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
When using multiple @patch decorators, it can get confusing to define your 
arguments in reverse order.  There are two ways I think this could be improved:

A) Reverse the set of args that are appended to the function call.

B) Pass the args in as kwargs instead.  The key could be the attribute name.

Both of these possibilities are backward incompatible though, unless a flag 
were provided.

Original issue reported on code.google.com by danielfalk22@gmail.com on 22 Aug 2010 at 10:11

GoogleCodeExporter commented 9 years ago 
I'm afraid I don't understand what you mean by "it can get confusing to define 
your arguments in reverse order". Can you provide an example showing how it is 
at the moment (hopefully I can then *see* what you mean by confusing) and how 
you would like it to be.

Original comment by fuzzyman on 23 Aug 2010 at 7:58

GoogleCodeExporter commented 9 years ago 
@patch(os.path.join)
@patch(os.path.isfile)
@patch(os.path.isdir)
def test_method(self, join, isfile, isdir):
    #test code here

The above code is wrong, but it's not obvious why (at least to me).  The 
problem is that the args should have been defined as (self, isdir, isfile, 
join) instead, which is reverse order.  What's worse is that it's not clear, 
but the join parameter will be set to the value of the isdir mock, and the 
isdir parameter will be set to the value of the join mock, making it harder to 
see where the actual problem is.

Now, mock could reverse the order of the args, and this would make the code 
somewhat more intuitive, but that still leaves it open for you to have the 
wrong mocks associated with the wrong name.  But it could also just provide 
them as kwargs, so you could define them in any order, and you will never have 
the wrong mock attached to the wrong name.

Hope this makes more sense.

Original comment by danielfalk22@gmail.com on 31 Aug 2010 at 3:12

GoogleCodeExporter commented 9 years ago 
Decorators are always applied from inner to outer in Python. Once you know that 
the order is natural. I'm afraid I'm not going to do function argument 
introspection and use some heuristic to try and 'guess' which mock belongs to 
which argument.

Original comment by fuzzyman on 31 Aug 2010 at 6:24

GoogleCodeExporter commented 9 years ago 
You wouldn't need introspection if you send the args in as keyword args.  
Python would take care of matching the arguments with the proper methods.

But anyway it's not a problem.  I know the reason for the reversal and yet 
still find it less pleasant to try to reverse it myself, but I've just changed 
my copy to work my way.  That's the beauty of open source I guess.

Original comment by danielfalk22@gmail.com on 1 Sep 2010 at 1:26

GoogleCodeExporter commented 9 years ago 
Ah, I see what you mean. That would require you to use specific names for your 
patched functions. It would be backwards compatible and wouldn't work for 
patch.object

I think just having a defined order is simpler, it's just a shame the order was 
wrong in earlier versions of mock.

Original comment by fuzzyman on 1 Sep 2010 at 2:10