On Thu, 15 Aug 2013 23:28:39 +0300, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
On 15 Aug 2013, at 21:10, "Eric V. Smith" <eric@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@pearwood.info <mailto:steve@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