This callback idea feels way over-engineered for this module. It would absolutely make sense in a more specialized numeric or statistical library. But `statistics` feels to me like it should be only simple and basic operations, with very few knobs attached.
On Mon, Jan 7, 2019, 2:36 PM MRAB <pyt...@mrabarnett.plus.com wrote: > On 2019-01-07 16:34, Steven D'Aprano wrote: > > On Mon, Jan 07, 2019 at 10:05:19AM -0500, David Mertz wrote: > [snip] > >> It's not hard to manually check for NaNs and > >> generate those in your own code. > > > > That is correct, but by that logic, we don't need to support *any* form > > of NAN handling at all. It is easy (if inefficent) for the caller to > > pre-filter their data. I want to make it easier and more convenient and > > avoid having to iterate over the data twice if it isn't necessary. > > > Could the functions optionally accept a callback that will be called > when a NaN is first seen? > > If the callback returns False, NaNs are suppressed, otherwise they are > retained and the function returns NaN (or whatever). > > The callback would give the user a chance to raise a warning or an > exception, if desired. > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
