On 16 Aug 2013, at 02:30, R. David Murray <rdmurray at bitdance.com> wrote: > On Thu, 15 Aug 2013 23:28:39 +0300, Michael Foord <fuzzyman at voidspace.org.uk> wrote: >> >> On 15 Aug 2013, at 21:10, "Eric V. Smith" <eric at 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 <steve at pearwood.info >>>> <mailto:steve at 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 :) > Hah. mock used to provide separate patch and patch_object "functions" (they're really just factory functions for classes) but "patch.object" and "patch.dict" are easy to remember and you only have to import a single object instead of a proliferation. In my experience it's been a better API. The separate function was deprecated and removed a while ago. Other parts of the mock API and architecture are somewhat legacy - it's a six year old project with a lot of users, so it's somewhat inevitable. If starting from scratch I wouldn't do it *very* differently though. Michael > --David > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
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