I did not compare performance (yet).  If there is a particular test 
case, I am happy to measure that.  Also, I made sure that the results 
and errors (!) for non-numeric items are the same as for the original, 
Slow Summation case.

The version I submitted is perhaps only slightly faster for most int and 
float cases, since it never creates and adds the 0 int default for the 
optional 'start' argument.

For other int and float cases it will certainly be faster.  Here are a 
few (extreme) examples.

1) Assume a long list consisting of one float followed by all ints.  The 
existing code will switch to the float loop at the very first float 
encountered and then use C double add (plus the FPE protection overhead) 
to add all subsequent ints.  My version will use C long adds for all 
ints, C double add for the float plus one C double add to combine the 
long and double results.

2) Consider a list of just 2 items, one float and one int (and no 
'start' argument).  The current code will first create a result object 
for the 'start' default 0.  Then, it enters the int loop (since result 
is an int, 0) and gets the first item, the float.  Since the item is not 
an int, it is added to the current result using PyNumber_Add.  Next, it 
falls into the float loop, since the result is now a float, presumably.  
Next, it gets the int item and adds that int as C double to the C double 
in f_result.  The end result C double f_result is returned as float.  
Quite costly for just one float and one int and maybe worse than than 
Slow Summation.

3) My version does not create a 0 int for the missing 'start'.  That is 
only created when absolutely needed at some later time.  In addition, 
all int items are added in C long i_sum and all floats are added in C 
double f_sum, regardless of the order they occur in the sequence.  At 
the end of the iteration loop, the C long i_sum is added to C double 
f_sum once and a single float object is created and returned.  That is 
very efficient and without any unnecessary overhead.

In other words, for sequences with mixed int and float objects the 
difference can be significant, depending on where the very first float 
item is located in the sequence and how may int follow.

However, for sequences with items of the same type, all int or all 
float, there will be little or no difference.  

/Jean Brouwers

PS) There are two additional things to consider for the float case:

- Ooverflow (ERANGE) and value (EDOM) errors in C double adds

- Using a compensating summation for floats, like Kahan's method.