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

[Ron Adam]

On 07/10/2013 04:58 PM, Sergey wrote:
> On Jul 9, 2013 Ron Adam wrote:
>
>>> Seriously, why there's so much holy wars about that? I'm not asking
>>> to rewrite cpython on Java or C#. I'm not adding a bunch of new
>>> functions, I'm not even changing signatures of existing functions.
>>
>> It's the nature of this particular news group.  We focus on improving
>> python, and that includes new things and improving old things, but also
>> includes discussing any existing or potential problems.
>>
>> You will almost always get a mix of approval and disapproval on just about
>> every thing here.  It's not a war, it's just different people having
>> different opinions.
>>
>> Quite often that leads to finding better ways to do things, and in the long
>> run, helps avoid adding features and changes that could be counter
>> productive to python.
>
> I must agree that I was indeed inspired with some new ideas during
> this discussion. It's just that those "inspirations" come in a very
> non-constructive form of "it makes no sense", "cannot always be fast",
> "you can't", "everyone else thinks you shouldn't", etc.
>
> 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? ;)
>
> 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
> — 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.

My advise is to not try so hard to change an individuals mind.

Are you familiar with the informal voting system we use?   Basically take a 
look though the discussion and look for +1,-1, or things inbetween or like 
those, and try to get a feel for how strong we feel as a group on the 
different suggestions.  It's not perfect.  What you are looking for is 
strong(er) indications one way or the other(more -1's or +1's), so you 
identify the suggestions that can be eliminated and the ones that are worth 
following up on.


>> 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. :)

I haven't checked that issue, but I'm guessing you were referred to here 
either because, their was a slight API change in your patch, or you were 
proposing an addition that would include a change, and so they suggested 
discussing it here first.  Or they wanted you to discuss the possibility of 
making some changes while you are doing this patch.

You can always go back with... "there was no consensus concerning... adding 
or removing... ", and ask to get just the speed increase parts approved. 
As long as it doesn't use ugly hacks or code that is difficult to maintain, 
it should be ok.  (and doesn't have any other side effects.)


My preference on this is to not extend the API, but go ahead and make it 
faster if you can.

Down the road, I'd like the API's of sum() and fsum() to match.  And for 
them to only work on numbers, and possibly be extended to work on vectors.

So.. make the numbers case faster, but probably don't bother changing the 
non numbers case.  (It seems like this is the preferred view so far.)

There might be some support for depreciating the non-numbers case.  I'm not 
sugesting that *you* do that btw... see below. :-)


>> 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. :(

These things that are expressed as *YOU* usually mean ... *WE*.  It's just 
an American English bad habit to overly use "you".   Python has millions of 
useers, so *WE* can't do a lot of things *WE* would like to do.  :-/


Cheers,
    Ron


>> It's what this board if for.  ;-)
>