Actually, I wouldn't mind passing a key function to _median(), but that is
way too advanced for the beginner users to have to think about.  So maybe
median() could call _median() internally where needed, but the underscore
version could exist also.

On Sun, Dec 29, 2019 at 8:14 PM Andrew Barnert <abarn...@yahoo.com> wrote:

> On Dec 29, 2019, at 16:08, David Mertz <me...@gnosis.cx> wrote:
> >
> > * There is absolutely no need to lose any efficiency by making the
> statistics functions more friendly.  All we need is an optional parameter
> whose spelling I've suggested as `on_nan` (but bikeshed freely).  Under at
> least one value of that parameter, we can keep EXACTLY the current
> implementation, with all its warts and virtues as-is.  Maybe a spelling for
> that option could be 'unsafe' or 'fast'?
>
> This seems like the right way to go to me.
>
> However, rather than coming up with appropriately-general implementations
> of each of these things, wouldn’t taking a key function to pass through to
> sorted be simpler for some? In particular, coming up with a total_order
> function that works for all valid number-like types is difficult; letting
> the user pass key=math.total_order or decimal.Decimal.compare_total or
> partial(decimal.Decimal.compare_total, context=my_context) or whatever is
> appropriate is a lot simpler and a lot more flexible. Anyone who knows
> that’s what they want should know how to pass it.
>
> Plus, finding the median_low or _high, with a key function actually seems
> useful even without NaNs. “Find the median employee by salary” doesn’t seem
> like a meaningless operation.
>
> A key function could also take care of raise, but not ignore or poison,
> and at least ignore seems like it’s needed. So your API still makes sense
> otherwise. (But, while we’re painting the shed, maybe enum values instead
> of bare strings? They could be StrEnum values where FAST.value == 'fast'
> for people who are used to Pandas, I suppose.)
>
> Maybe the is_nan function could also be a parameter, like the key
> function. By default it’s just the method with a fallback to math or cmath
> (or it’s just the method, and float and complex add those methods, or it’s
> a new function that calls a new protocol method, or whatever). That doesn’t
> work for every possible type that might otherwise work with statistics, but
> if you have some other type—or want some other unusual but sensible
> behavior (e.g., you’re the one guy who actually needs to ignore qNaNs but
> raise early on sNaNs), you can write it and pass it. I’m still not
> convinced anyone will ever want anymore other than the method/math/cmath
> version, but if they do, I think they’d know it and be fine with passing it
> in explicitly.
>
> As far as your implementation, I don’t think anything but ignore needs to
> preprocess things. Raise can just pass a key function that raises on NaN to
> sorted. Poison can do the same but handle the exception by returning NaN.
> Who cares that it might take slightly longer to hit the first NaN that way
> than by doing an extra pass, if it’s simpler and slightly faster for the
> non-exceptional case?
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7XLJCT2SM2VTRXGSOSF5JZ6EWUA7XICY/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to