On Thu, 15 Aug 2013 23:28:39 +0300, Michael Foord <fuzzy...@voidspace.org.uk> wrote: > > On 15 Aug 2013, at 21:10, "Eric V. Smith" <e...@trueblade.com> wrote: > > > On 08/15/2013 01:58 PM, Mark Dickinson wrote: > >> On Thu, Aug 15, 2013 at 2:08 PM, Steven D'Aprano <st...@pearwood.info > >> <mailto:st...@pearwood.info>> wrote: > >> > >> > >> - Each scheme ended up needing to be a separate function, for ease > >> of both implementation and testing. So I had four private median > >> functions, which I put inside a class to act as namespace and avoid > >> polluting the main namespace. Then I needed a "master function" to > >> select which of the methods should be called, with all the > >> additional testing and documentation that entailed. > >> > >> > >> That's just an implementation issue, though, and sounds like a minor > >> inconvenience to the implementor rather than anything serious; I don't > >> think that that should dictate the API that's used. > >> > >> - The API doesn't really feel very Pythonic to me. For example, we > >> write: > >> > >> > >> And I guess this is subjective: conversely, the API you're proposing > >> doesn't feel Pythonic to me. :-) I'd like the hear the opinion of other > >> python-dev readers. > > > > I agree with Mark: the proposed median, median.low, etc., doesn't feel > > right. Is there any example of doing this in the stdlib? I suggest just > > median(), median_low(), etc. > > > > If we do end up keeping it, simpler than the callable singleton is: > > > >>>> def median(): return 'median' > > ... > >>>> def _median_low(): return 'median.low' > > ... > >>>> median.low = _median_low > >>>> del _median_low > >>>> median() > > 'median' > >>>> median.low() > > 'median.low' > > > There's the patch decorator in unittest.mock which provides: > > patch(...) > patch.object(...) > patch.dict(...) > > The implementation is exactly as you suggest. (e.g. patch.object = > _patch_object)
Truthfully there are a number of things about the mock API that make me uncomfortable, including that one. But despite that I'm glad we didn't try to re-engineer it. Take that as you will :) --David _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
