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.
Cheers,
Ron
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
