[Python-Dev] sum(...) limitation
Chris Barker - NOAA Federal
chris.barker at noaa.gov
Mon Aug 11 17:07:39 CEST 2014
> I'm very sympathetic to Steven's explanation that "we
> wouldn't be having this discussion if we used a different operator for
> string concatenation".
Sure -- but just imagine the conversations we could be having instead
: what does bit wise and of a string mean? A bytes object? I cod see
it as a character-wise and, for instance ;-)
My confusion is still this:
Repeated summation of strings has been optimized in cpython even
though it's not the recommended way to solve that problem.
So why not special case optimize sum() for strings? We are already
special-case strings to raise an exception.
It seems pretty pedantic to say: we cod make this work well, but we'd
rather chide you for not knowing the "proper" way to do it.
Practicality beats purity?
> Although that's not the whole story: in
> practice even numerical sums get split into multiple functions because
> floating point addition isn't associative, and so needs careful
> treatment to preserve accuracy. At that point I'm strongly +1 on
> abandoning attempts to "rationalize" summation.
> I'm not sure how I'd feel about raising an exception if you try to sum
> any iterable containing misbehaved types like float. But not only
> would that be a Python 4 effort due to backward incompatibility, but
> it sorta contradicts the main argument of proponents ("any type
> implementing __add__ should be sum()-able").
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
More information about the Python-Dev