Robert Collins added the comment: 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) or # separate object to get at the mock housekeeping vs the mocked interface mocki(a_mock).returnvalue = 3 etc. 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'. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24651> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
