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 stdlib. 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 error*. -Rob -- Robert Collins <rbtcollins at hp.com> Distinguished Technologist HP Converged Cloud
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