Nick Coghlan added the comment:
Claiming to commit before 3.4rc1 (as I believe Steven's SSH key still needs to
be added)
--
assignee: stevenjd - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20481
Roundup Robot added the comment:
New changeset 5db74cd953ab by Nick Coghlan in branch 'default':
Close #20481: Disallow mixed type input in statistics
http://hg.python.org/cpython/rev/5db74cd953ab
--
nosy: +python-dev
resolution: - fixed
stage: needs patch - committed/rejected
status:
Nick Coghlan added the comment:
OK, I committed a slight variant of Steven's patch:
- I moved the issue 20389 doc changes to a separate patch that I uploaded over
there
- Steven had marked one of the tests as potentially obsolete, I just removed it
entirely. If we decide we eventually want
Oscar Benjamin added the comment:
Close #20481: Disallow mixed type input in statistics
If I understand correctly the reason for hastily pushing this patch
through is that it's the safe option: disallow mixing types as a quick
fix for soon to be released 3.4. If we want to allow mixing types
Nick Coghlan added the comment:
Yes, a new RFE to sensibly handle mixed type input in 3.5 would make sense (I
did something similar for the issue where we removed the special casing of
Counter for 3.4).
--
___
Python tracker rep...@bugs.python.org
Steven D'Aprano added the comment:
Attached is a patch which:
- documents that mixed types are not currently supported;
- changes the behaviour of _sum to raise TypeError on mixed input
types (mixing int and other is allowed, but nothing else);
- updates the tests;
- adds some
Nick Coghlan added the comment:
I think it's also acceptable at this point for the module docs to just say that
handling of mixed type input is undefined and implementation dependent, and
recommend doing map(int, input_data), map(float, input_data), map(Decimal,
input_data) or map(Fraction,
Oscar Benjamin added the comment:
I was working on the basis that we were talking about Python 3.5.
But now I see that it's a 3.4 release blocker. Is it really that urgent?
I think the current behaviour is very good at handling a wide range of types.
It would be nice to consistently report
Nick Coghlan added the comment:
Changing the behaviour is not urgent - documenting that it may change
in the future is essential.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20481
___
Wolfgang Maier added the comment:
Hi Nick and Oscar,
my patch including tests is ready. What else should I say than that I think it
is ok, but of course with only days remaining and still no feedback from
Steven, I'm not sure there is any chance for it going into 3.4 still.
Anyway, before
Steven D'Aprano added the comment:
Wolfgang,
Thanks for the patch, I have some concerns about it, but the basic idea
does look reasonable. However, I've been convinced that supporting mixed
types at all needs more careful thought. Under the circumstances, I'm
more concerned about making sure
Wolfgang Maier added the comment:
Hi Steven,
sounds reasonable, still here's the patch in diff version.
Its rules for type coercion are detailed in _coerce_types's docstring.
Questions and comments are welcome.
Best,
Wolfgang
--
keywords: +patch
Added file:
Oscar Benjamin added the comment:
It's not as simple as registering with an ABC. You also need to provide the
interface that the ABC represents:
import sympy
r = sympy.Rational(1, 2)
r
1/2
r.numerator
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'Half'
Wolfgang Maier added the comment:
there are currently two strict requirements for any numeric type to be usable
with statistics._sum:
I meant *three* of course (remembered one only during writing).
--
___
Python tracker rep...@bugs.python.org
Wolfgang Maier added the comment:
Just to make sure that this discussion is not getting on the wrong track,
there are currently two strict requirements for any numeric type to be usable
with statistics._sum:
(1) the type has to provide either
- numerator/denominator properties or
- an
Oscar Benjamin added the comment:
I agree that supporting non-stdlib types is in some ways a separate issue from
how to manage coercion with mixed stdlib types. Can you provide a complete
patch (e.g. hg diff coerce_types.patch).
http://docs.python.org/devguide/
There should probably also be
Wolfgang Maier added the comment:
Once the input numbers are converted to float statistics._sum can handle
them perfectly well. In this case I think the output should also be a float so
that it's clear that precision may have been lost. If the precision of float
is not
what the user wants
Changes by Steven D'Aprano steve+pyt...@pearwood.info:
--
assignee: - stevenjd
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20481
___
___
Oscar Benjamin added the comment:
Wolfgang have you tested this with any third party numeric types from
sympy, gmpy2, mpmath etc.?
Last I checked no third party types implement the numbers ABCs e.g.:
import sympy, numbers
r = sympy.Rational(1, 2)
r
1/2
isinstance(r, numbers.Rational)
False
Wolfgang Maier added the comment:
Hi Oscar,
well, I haven't used sympy much, and I have no experience with the others, but
in light of your comment I quickly checked sympy and gmpy2.
You are right about them still not using the numbers ABCs, however, on your
advise I also checked how the
New submission from Nick Coghlan:
I haven't completely following the type coercion discussion on python-ideas.
but the statistics module at least needs a docs clarification (to explain that
the current behaviour when mixing input types is not fully defined, especially
when Decimal is
Wolfgang Maier added the comment:
Thanks Nick for filing this!
I've been working on modifications to statistics._sum and
statistics._coerce_types that together make the module's behaviour independent
of the order of input types (by making the decision based on the set of input
types) and,
22 matches
Mail list logo
