[Python-ideas] Fast sum() for non-numbers - why so much worries?

[Andrew Barnert]

On Jul 10, 2013, at 14:58, Sergey <sergemp at mail.ru> wrote:

> On Jul 9, 2013 Ron Adam wrote:
> 
> Or is that a lifehack [1] in action? I.e. "You can't make it fast for
> that type. Oh, you can? Then you can't make it fast for that type.
> Oh, you did that too? But you can't make it fast for all the types!"
> What if I can? ;)

But you haven't found a workable solution for all of the other types people have brought up--or even for a single one of them. So that's a serious misrepresentation.

> It's just instead of discussing what is the best way to fix a slowness,
> I'm spending most time trying to convince people that slowness should
> be fixed.
> — sum is slow for lists, let's fix that!
> — you shouldn't use sum...
> — why can't I use sum?
> — because it's slow

But that's not why you shouldn't use sum. So, you're trying to answer people who (a) are wrong, and (b) aren't on this list instead of answering the people who are actually here.

Besides, being fast for list and tuple but slow for other collection types would be an attractive nuisance. Your only response to that has been to claim that it can be fast for every possible collection type, but it can't. You haven't gotten it to work. And there are good reasons to believe it's not just hard, but impossible.

So, if that's true, where does it leave you? You can't argue that sum is the obvious way to concatenate collections.  You either have to say that it's the obvious way to concatenate only builtin collections, and something else should be used for everything else, or you have to argue that the benefits to novices who do the wrong thing with tuples outweighs the costs. Or, of course, accept that it's not a good idea.

> — then let's fix that!
> — you shouldn't use sum...
> I haven't thought that somebody can truly believe that something should
> be slow, and will find one excuse after another instead of just fixing
> the slowness.

Calling recv(1) over and over on a socket is slow. We could fix that by adding an implicit buffer to all socket objects. Can you believe that someone might object to that patch?

>> If it only makes an existing function faster and doesn't change any other 
>> behaviour, and all the tests still pass for it.  Just create an issue on 
>> the tracker, with the patch posted there, and it will probably be accepted 
>> after it goes through a much more focused review process.
> 
> I've done that first [2] And there I was asked to write here. :)
> 
>> But discussing it here will invite a lot of opinions about how it works, 
>> how it shouldn't work, what would work better, and etc...
> 
> And about what *I* shouldn't do, what *I* can't and what *I* need.
> As if I'm the bug that should be fixed. :(
> 
>> It's what this board if for.  ;-)
> 
> -- 
> [1] http://bash.org/?152037
> [2] http://bugs.python.org/issue18305
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas