<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 11, 2014 at 11:07 PM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">I'm referring to removing the unnecessary information that there's a<br>
</div>
better way to do it, and simply raising an error (as in Python 3.2,<br>
say) which is all a RealProgrammer[tm] should ever need!<br></blockquote><div><br></div><div>I can't imagine anyone is suggesting that -- disallow it, but don't tell anyone why? </div><div><br></div><div>The only thing that is remotely on the table here is:</div>
<div><br></div><div>1) remove the special case for strings -- buyer beware -- but consistent and less "ugly"</div><div><br></div><div>2) add a special case for strings that is fast and efficient -- may be as simple as calling "".join() under the hood --no more code than the exception check.</div>
<div><br></div><div>And I doubt anyone really is pushing for anything but (2)</div><div><br></div><div>Steven Turnbull wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px"> IMO we'd also want a homogeneous_iterable ABC</span></blockquote><div><br></div><div>Actually, I've thought for years that that would open the door to a lot of optimizations -- but that's a much broader question that sum(). I even brought it up probably over ten years ago -- but no one was the least bit iinterested -- nor are they now -- I now this was a rhetorical suggestion to make the point about what not to do....</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"> Because obviously we'd want the<br>
</span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">attractive nuisance of "if you have __add__, there's a default<br></span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">definition of __sum__" </span></blockquote>
<div><br></div><div>now I'm confused -- isn't that exactly what we have now?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">It's possible that Python could provide some kind of feature that<br></span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">would allow an optimized sum function for every type that has __add__,<br>
</span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">but I think this will take a lot of thinking. </span></blockquote><div><br></div><div>does it need to be every type? As it is the common ones work fine already except for strings -- so if we add an optimized string sum() then we're done.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"> *Somebody* will do it<br>
</span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">(I don't think anybody is +1 on restricting sum() to a subset of types<br></span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">with __add__). </span></blockquote>
<div><br></div><div>uhm, that's exactly what we have now -- you can use sum() with anything that has an __add__, except strings. Ns by that logic, if we thought there were other inefficient use cases, we'd restrict those too.</div>
<div><br></div><div>But users can always define their own classes that have a __sum__ and are really inefficient -- so unless sum() becomes just for a certain subset of built-in types -- does anyone want that? Then we are back to the current situation:</div>
<div><br></div><div>sum() can be used for any type that has an __add__ defined.</div><div><br></div><div>But naive users are likely to try it with strings, and that's bad, so we want to prevent that, and have a special case check for strings.</div>
<div><br></div><div>What I fail to see is why it's better to raise an exception and point users to a better way, than to simply provide an optimization so that it's a mute issue.</div><div><br></div><div>The only justification offered here is that will teach people that summing strings (and some other objects?) is order(N^2) and a bad idea. But:</div>
<div><br></div><div>a) Python's primary purpose is practical, not pedagogical (not that it isn't great for that)</div><div><br></div><div>b) I doubt any naive users learn anything other than "I can't use sum() for strings, I should use "".join()". Will they make the leap to "I shouldn't use string concatenation in a loop, either"? Oh, wait, you can use string concatenation in a loop -- that's been optimized. So will they learn: "some types of object shave poor performance with repeated concatenation and shouldn't be used with sum(). So If I write such a class, and want to sum them up, I'll need to write an optimized version of that code"?</div>
<div><br></div><div>I submit that no naive user is going to get any closer to a proper understanding of algorithmic Order behavior from this small hint. Which leaves no reason to prefer an Exception to an optimization.</div>
<div><br></div><div>One other point: perhaps this will lead a naive user into thinking -- "sum() raises an exception if I try to use it inefficiently, so it must be OK to use for anything that doesn't raise an exception" -- that would be a bad lesson to mis-learn....</div>
<div><br></div><div>-Chris</div><div><br></div><div>PS: </div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Armin Rigo wrote:</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">It also improves a<br></span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">lot the precision of sum(list_of_floats) (though not reaching the same<br>
</span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">precision levels of math.fsum()).</span></blockquote><div><br></div><div>while we are at it, having the default sum() for floats be fsum() would be nice -- I'd rather the default was better accuracy loser performance. Folks that really care about performance could call math.fastsum(), or really, use numpy...</div>
<div><br></div><div>This does turn sum() into a function that does type-based dispatch, but isn't python full of those already? do something special for the types you know about, call the generic dunder method for the rest.</div>
<div><br></div><div><br></div><div><br></div></div>-- <br><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>
Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>
</div></div>