On Thu, Aug 15, 2013 at 6:48 PM, Ryan <rym...@gmail.com> wrote:
> For the naming, how about changing median(callable) to median.regular?
> That way, we don't have to deal with a callable namespace.
>
Hmm. That sounds like a step backwards to me: whatever the API is, a
simple "from statistics import median; m = median(my_data)" should still
work in the simple case.
Mark
>
> Steven D'Aprano <st...@pearwood.info> wrote:
>
>> On 15/08/13 21:42, Mark Dickinson wrote:
>>
>>> The PEP and code look generally good to me.
>>>
>>> I think the API for median and its variants deserves some wider discussion:
>>> the reference implementation has a callable 'median', and variant callables
>>> 'median.low', 'median.high', 'median.grouped'. The pattern of attaching
>>> the variant callables as attributes on the main callable is unusual, and
>>> isn't something I've seen elsewhere in the standard library. I'd like to
>>> see some explanation in the PEP for why it's done this way. (There was
>>> already some discussion of this on the issue, but that was more centered
>>> around the implementation than the API.)
>>>
>>> I'd propose two alternatives for this: either have separate functions
>>> 'median', 'median_low', 'median_high', etc., or have a single function
>>> 'median' with a "method" argument that takes a string specifying
>>> computation using a particular method. I don't see a really good reason to
>>> deviate from standard patterns here, and fear that users would find the
>>> current API surprising.
>>
>>
>> Alexander Belopolsky has convinced me (off-list) that my current
>> implementation is better changed to a more conservative one of a callable
>> singleton instance with methods implementing the alternative computations.
>> I'll have something like:
>>
>>
>> def _singleton(cls):
>> return cls()
>>
>>
>> @_singleton
>> class median:
>> def __call__(self, data):
>> ...
>> def low(self, data):
>> ...
>> ...
>>
>>
>> In my earlier stats module, I had a single median function that took a
>> argument to choose between alternatives. I called it "scheme":
>>
>> median(data, scheme="low")
>>
>> R uses parameter
>> called "type" to choose between alternate calculations, not for median as we
>> are discussing, but for quantiles:
>>
>> quantile(x, probs ... type = 7, ...).
>>
>> SAS also uses a similar system, but with different numeric codes. I rejected
>> both "type" and "method" as the parameter name since it would cause
>> confusion with the usual meanings of those words. I eventually decided
>> against this system for two reasons:
>>
>> - 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.
>>
>> - The API doesn't really feel very Pythonic to me. For example, we write:
>>
>> mystring.rjust(width)
>> dict.items()
>>
>> rather than mystring.justify(width,
>> "right") or dict.iterate("items"). So I think individual methods is a better
>> API, and one which is more familiar to most Python users. The only
>> innovation (if that's what it is) is to have median a callable object.
>>
>>
>> As far as having four separate functions, median, median_low, etc., it just
>> doesn't feel right to me. It puts four slight variations of the same
>> function into the main namespace, instead of keeping them together in a
>> namespace. Names like median_low merely simulates a namespace with
>> pseudo-methods separated with underscores instead of dots, only without the
>> advantages of a real namespace.
>>
>> (I treat variance and std dev differently, and make the sample and
>> population forms separate top-level functions rather than methods, simply
>> because they are so well-known from scientific calculators that it is
>> unthinkable to me to do differently. Whenever I use numpy, I am surprised
>> all over again that it has only a single variance function.)
>>
>>
>>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> 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/dickinsm%40gmail.com
>
>
_______________________________________________
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
