[Python-Dev] How far to go with user-friendliness

Robert Collins robertc at robertcollins.net
Sat Jul 18 06:18:05 CEST 2015

On 18 July 2015 at 15:19, Nick Coghlan <ncoghlan at gmail.com> wrote:

> This change *doesn't really matter* in the grand scheme things, but would
> require a non-zero amount of time and effort to reverse, so unless you're
> offering one of the unittest maintainers a contract gig to change it back,
> let it go.

s/unittest/mock :). But yes.

Currently only Michael is listed under 'experts' in the devguide for
unittest.mock. I've taken up the baton to keep the backport up to
date, to keep the ecosystem healthy, but I've no specific plans to
hack on mock per se. .... I think we'd probably benefit from more
names there :) I know Kushal and Berker have been doing things in the

But there's a tonne of important work to do before worrying about
tweaking a patch which was peer reviewed and went through the entirely
normal development process to address a critical usability issue with
mock. Which, judging from this thread, a bunch of folk don't actually
understand in the first place. [I mean no disrespect here, but there
have been multiple explanations trying to cover the distinction about
what is actually going on, and I'm well over them].

So - folk interested in unittest.mock. If you want to help, going
through the 200 open issues in https://github.com/testing-cabal/mock,
starting with the oldest, assessing whether they are:
 - still relevant
 - present only in the backport (leave them where they are)
 - or in 3.6 as well (in which case open a new ticket at
https://bugs.python.org/ linked to the github issue, and either close
the github issue or label it upstream (or both)).

THAT would be valuable, and improve users experience of unittest.mock
[and mock] much more than making a_mock.assret_called_once *not


Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

More information about the Python-Dev mailing list