This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rbcollins
Recipients berker.peksag, bignose, brett.cannon, carljm, erik.bray, fov, kevinbenton, kushal.das, michael.foord, poke, rbcollins, ztane
Date 2015-07-25.18:59:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Some great points raised here.

Yes, we'd need .calls and .returnvalue and so on all made accessible via another route, and that would be a less direct spelling.

e.g. a_mock.returnvalue = 3
# function
set_returnvalue(a_mock, 3)
# separate object to get at the mock housekeeping vs the mocked interface
mocki(a_mock).returnvalue = 3


None of which make me want to say 'wow thats a great api'.

I wouldn't want to advocate for a patch for this unless:
 - it would feel as convenient to use as the current API does
 - it would be possible to be both forward and backwards compatible with the existing API indefinitely: There are lots of users of mock, and offering a [presumably] improved API is not worth turning all that code into an instant sea-anchor: if we're going to change this, we need to do so in a -very- graceful fashion, because unlike e.g. the mock_open things that only affect some users of mock, this would (if done poorly) break every user ever.

For clarity, I have no plans to write such a patch at this time, though if someone did come up with a proof of concept I'd happily review it, and dig up Michael to get his thoughts *if and only if* it met the two constraints above.

I'm not sure of the right bug tracker state to say 'this is a maybe, maintainer isn't enthused about it'.
Date User Action Args
2015-07-25 18:59:33rbcollinssetrecipients: + rbcollins, brett.cannon, carljm, michael.foord, poke, bignose, erik.bray, berker.peksag, kushal.das, ztane, fov, kevinbenton
2015-07-25 18:59:33rbcollinssetmessageid: <>
2015-07-25 18:59:33rbcollinslinkissue24651 messages
2015-07-25 18:59:32rbcollinscreate