[Python-Dev] PEP 450 adding statistics module

[R. David Murray]

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 :)

--David