[Python-Dev] PEP 450 adding statistics module

[Michael Foord]

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