[Python-3000] Python 3000 Status Update (Long!)

[Ron Adam]

Steve Howell wrote:
> --- Ron Adam <rrr at ronadam.com> wrote:
> 
>>
>> Bill Janssen wrote:
>>>> I think you were missing my point, which is that
>> sum
>>>> doesn't and shouldn't necessarily have the same
>>>> semantics as map(+).
>>> It's not that I don't understand your argument,
>> Steve.
>>> I just don't find it effective.  If we are going
>> to distinguish
>>> between "arithmetic addition" and "concatenation",
>> we should find
>>> another operator.
>>>
>>> As long as we *don't* do that, my personal
>> preference would be to
>>> either remove "sum" completely, or have it work in
>> a regular fashion,
>>> depending on which data type is passed to it,
>> either as arithmetic
>>> addition or as sequence concatenation.
>>  From the standpoint of readability and being able
>> to know what a 
>> particular section of code does I believe it is
>> better to have limits that 
>> make sense in cases where the behavior of a function
>> may change based on 
>> what the data is.
>>
>> My preference would be to limit sum() to value
>> addition only, and never do 
>> concatenation.  For bytes types, it could be the
>> summing of bytes.  This 
>> could be useful for image data.  For all non numeric
>> types it would 
>> generate an exception.
>>
>> And if a general function that joins and/or extends
>> is desired, a separate 
>> function possibly called merge() might be better. 
>> Then sum() would always 
>> do numerical addition and merge() would always do
>> concatenation of objects. 
>> That makes the code much easier to read 6 months
>> from now with a lower 
>> chance of having subtle bugs.
>>
>> The main thing for me is how quickly I can look at a
>> block of code and 
>> determine what it does with a minimum of back
>> tracking and data tracing.
>>
> 
> Ron, I obviously agree with your overriding points
> 100%, and thank you for expressing them better than I
> did, but I would object to the name merge().  "Merge"
> to me has the semantics of blending strings, not
> joining them.  English already has two perfectly well
> understood words for this concept:
> 
>    "abc", "def" -> "abcdef"
> 
> The two English words are "join" and "concatenate." 
> Python wisely chose the shorter word, although I can
> see arguments for the longer word, as "join" probably
> is a tiny bit more semantically overloaded than
> "concatenate."
> 
> The best slang word for the above is "mush."

Yes, join is the better choice for strings only, but I think the discussion 
was also concerned with joining sequences of other types as well. 
list.join() or tuple.join() doesn't work.


For joining sequences we have...

     str.join()
     list.extend()   # but returns None

Sets have an have a .union() method, but it only works on two sets at a time.

There is no equivalent of .extend() for tuples.  There is an .__add__() method.

A join() function or generator might be able to unify these operations and 
remove the need for sum() to do this.  It can't be a method as it would 
break the general rule that an object should not mutate itself and also 
return it self.


As for the numeric cases...

There are no int or float methods to get a single value from a sequence of 
values.  So we need to use a function or some other way of doing it.  So 
sum is needed for this.  (well, it's nice to have.)

Currently our choices are:

     sum(seq)

     reduce(lambda x, y: x+y, seq)  # not limited to addition

Summing items across sequences of same length might be a sumitems() 
function.  But then we are getting into numeric territory.

The more complex uses of these are probably just as well done with a for 
loop.

Cheers,
    Ron