总和和字符串 [英] sum and strings
问题描述
我正在浏览Flattening Lists上的Voidspace博客项目，并且
跟进使用sum来进行展平。
解决方案是：
I was browsing the Voidspace blog item on "Flattening Lists", and
followed up on the use of sum to do the flattening.
A solution was:
>> nestedList = [[1,2]，[3,4] ，[5,6]]
sum（nestedList，[]）
>>nestedList = [[1, 2], [3, 4], [5, 6]]
sum(nestedList,[])
[1,2,3,4 ，5,6]
我不会想到以这种方式使用sum。当我帮助（总和）
时，文档字符串是以数字为中心的：它更进一步，并且排除了
它在字符串上的使用：
[1, 2, 3, 4, 5, 6]
I would not have thought of using sum in this way. When I did help(sum)
the docstring was very number-centric: It went further, and precluded
its use on strings:
>> help（sum）
>>help(sum)
模块中内置函数求和的帮助__builtin __：
sum（...）
sum（sequence，start = 0 ）-value
返回一系列数字（非字符串）加上
值
参数''的总和开始''。当序列为空时，返回开始。
字符串排除对鸭子打字（一般）没有帮助，所以
我决定咨询参考资料总和：
总和（序列[，开始]）
总和开始和序列的项目，从左到右，并返回
总额。 start默认为0.序列的项目通常是
数字，不允许是字符串。快速，正确的方法来连接字符串串联是通过调用''''。join（sequence）。注意
总和（range（n），m）相当于reduce（operator.add，range（n），
m）版本2.3中的新功能。
上面对我来说是一个更好的描述，并且带着一个
好奇心，我想我可能想出了使用
总和嵌套嵌套列表:-)
但是仍然存在关于使用字符串的警告。
因此，我尝试了总和与它们的减少等价物相比。 for strings：
Help on built-in function sum in module __builtin__:
sum(...)
sum(sequence, start=0) -value
Returns the sum of a sequence of numbers (NOT strings) plus the
value
of parameter ''start''. When the sequence is empty, returns start.
The string preclusion would not help with duck-typing (in general), so
I decided to consult the ref doc on sum:
sum( sequence[, start])
Sums start and the items of a sequence, from left to right, and returns
the total. start defaults to 0. The sequence''s items are normally
numbers, and are not allowed to be strings. The fast, correct way to
concatenate sequence of strings is by calling ''''.join(sequence). Note
that sum(range(n), m) is equivalent to reduce(operator.add, range(n),
m) New in version 2.3.
The above was a lot better description of sum for me, and with an
inquisitive mind, I like to think that I might have come up with using
sum to flatten nestedList :-)
But there was still that warning about using strings.
I therefore tried sum versus their reduce "equivalent" for strings:
>> import operator
reduce（operator.add ，ABCD.split（），''''）
>>import operator
reduce(operator.add, "ABCD".split(), '''')
''ABCD''
''ABCD''
>> sum（" ABCD" .split（），''''）
>>sum("ABCD".split(), '''')
Traceback（最近一次调用最后一次）：
文件"< interactive input>"，第1行， in？
TypeError：sum（）不能求和字符串[使用''''。join（seq）代替]
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
TypeError: sum() can''t sum strings [use ''''.join(seq) instead]
>>>
>>>
好了，经过以上所有，有一个问题：
为什么不呢为字符串做总和工作吗？
它会删除看起来像是任意限制的东西并且帮助
鸭子打字。如果答案是总和优化对于字符串数据类型不起作用，那么将一个陷阱放在
和代码中是不是更好将字符串转移到减少等价物？
只是想一想，
- 帕迪。
Well, after all the above, there is a question:
Why not make sum work for strings too?
It would remove what seems like an arbitrary restriction and aid
duck-typing. If the answer is that the sum optimisations don''t work for
the string datatype, then wouldn''t it be better to put a trap in the
sum code diverting strings to the reduce equivalent?
Just a thought,
- Paddy.
推荐答案
Sybren Stuvel写道：
Sybren Stuvel wrote:
>为什么不对字符串进行求和？
> Why not make sum work for strings too?
由于应该只有一种方法可以做到这一点，而且这种方式应该是明显的b $ b。
Because of "there should only be one way to do it, and that way should
be obvious".
我会想到性能和正确使用英语然而，
更相关。
< / F>
I would have thought that "performance" and "proper use of English" was
more relevant, though.
</F>
Sybren Stuvel< sy ******* @ YOURthirdtower.com.imaginationwrites：
Sybren Stuvel <sy*******@YOURthirdtower.com.imaginationwrites:
因为只有一种方法可以做到这一点，并且这种方式应该是明显的b $ b。已有str.join和unicode.join方法，
Because of "there should only be one way to do it, and that way should
be obvious". There are already the str.join and unicode.join methods,
这些很明显???
Those are obvious???
Paul Rubin写道：
Paul Rubin wrote:
Sybren Stuvel< sy ******* @ YOURthirdtower.com.imaginationwrites：
Sybren Stuvel <sy*******@YOURthirdtower.com.imaginationwrites:
>由于应该只有一种方法可以做到这一点，并且那种方式应该是显而易见的。已经有str.join和unicode.join方法，
>Because of "there should only be one way to do it, and that way should
be obvious". There are already the str.join and unicode.join methods,
那些很明显???
Those are obvious???
为什么要尝试总结字符串？此外，''''。join成语在Python中很常见。
在这种特殊情况下，''''。join要快得多比sum（）这就是为什么
sum（）拒绝连续字符串。
Georg
Why would you try to sum up strings? Besides, the ''''.join idiom is quite
common in Python.
In this special case, ''''.join is much faster than sum() which is why
sum() denies to concat strings.
Georg
这篇关于总和和字符串的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
