StringIO提案：添加__iadd__ [英] StringIO proposal: add __iadd__
问题描述
我总是找到字符串构建成语
temp_list = []
for x in various_pieces_of_output（）：
v = go_figure_out_some_string（）
temp_list.append（v）
final_string =''''。join（temp_list）
完全令人厌恶。作为替代，我建议
temp_buf = StringIO（）
for various_pieces_of_output（）：
v = go_figure_out_some_string（）
temp_buf + = v
final_string = temp_buf.getvalue（）
这里，temp_buf + = v应该与temp_buf.write（v）相同。
所以建议将一个__iadd__方法添加到StringIO和cStringIO。
有什么想法吗？
另外，我想知道现在可以消除现有的StringIO
模块（将其作为cStringIO的别名）现在新式的类
允许扩展cStringIO.StringIO。
Paul Rubin< http：// ph ****@NOSPAM.invalid>写道：
...temp_buf = StringIO（）
for various_pieces_of_output（）：
v = go_figure_out_some_string（）
temp_buf + = v
final_string = temp_buf.getvalue（）
这里，temp_buf + = v应该与temp_buf.write（v）相同。
因此建议将一个__iadd__方法添加到StringIO和cStringIO。
拼写x.write（v）作为x + = v的附加值是多少？是否值得
有一个允许+ =而不是+的类的完全陌生（
只有std库中的一个，我认为会是这样）.. 。？
有什么想法吗？
我认为您喜欢的代码片段和我刚刚引用的代码很好，
只需将+ =更改为写入。
另外，我想知道现在可以消除现有的StringIO
模块（使其成为cStringIO的别名），因为新式类允许扩展cStringIO.StringIO。
我喜欢拥有任何C编码标准库的纯Python版本
模块（的确，我希望我有更多！ - ）出于各种原因，包括减轻将Python移植到奇怪平台的负担。在StringIO'
的情况下，能够使用上面的成语连接Unicode
字符串就像普通字符串一样容易，例如 - - cStringIO（比如
文件对象）想要简单的字节串。
这样会很好（在Py3k中，当向后兼容性可以被破坏时）
来制作普通命名的默认用C编码的模块，因为它们被更频繁地使用，并找到另一个约定来表示纯粹的等价物 - 例如，pickle / pypickle和StringIO / pyStringIO
而不是当前的cPickle / pickle和cStringIO / StringIO。但是我希望这个纯粹的python参考能够支持
。模块留在那里（事实上，我会
喜欢他们_proliferate_，也许是在某些时候采用了一些工作：b
pypy guys;） 。
Alex
al *** @ mail .comcast.net （Alex Martelli）写道：拼写x.write（v）作为x + = v的附加值是多少？是否值得
让一个允许+ =而不是+的类完全陌生（在std库中只有一个，我认为它会是......）？
当然，+也可以支持。将两个StringIO'或StringIO添加到
字符串会导致StringIO具有明显的内容。
在StringIO的情况下，它是'很高兴能够使用上面的成语来连接Unicode字符串就像普通字符串一样容易，例如 - cStringIO（比如文件对象）想要简单的字节串。
我不知道这个限制 - 也许cStringIO可以扩展
来取Unicode。您将使用编码或解码方法来获取
字节串。或者可能有一个可变字符串类与cStringIO分开
，用于此目的（摆脱
list.append kludge）。
但我希望pure-python引用模块留在周围（而且，确实，我希望他们能够_poliferate_，或许在某些时候采用一些pypy家伙的工作;）。
也许这些东西的标准版本可以写在PyPy下的
RPython中，所以他们将编译成快速的机器代码，然后
不需要C版本。但是对于CPython，我认为我们需要
C版本。
Paul Rubin< http：// ph **** @ NOSPAM。无效>写道：
...在StringIO的情况下，很高兴能够使用上面的成语来
连接Unicode字符串就像普通字符串一样容易，例如 - cStringIO（比如文件对象）想要简单的字节串。
我不知道这个限制 - 也许cStringIO可以扩展
取Unicode。你将使用编码或解码方法来获得一个
字节串。
但为什么我不能有完美的多态性附加一个一堆字符串
在一起，就像我现在一样（用''''.join表示字符串列表，或者
StringIO），不关心是否字符串是Unicode还是
bytestrings？
或者可能有一个与cStringIO分开的可变字符串类，用于此目的（摆脱
list.append kludge）。
StringIO工作正常。开发（并且必须记录，学习，
教，...）一个单独的界面只是为了删除StringIO确实不值得。至于扩展cStringIO.write，我猜那可能是'b
，但不是没有破坏兼容性（现在使用的代码是使用unicode字符串写的
，假设它们''将通过默认编码编码到
字节字符串中，并且类似地假设getvalue
在cStringIO实例上调用时始终返回字节字符串）;你需要另外两个方法，或者等待Py3k。
但我希望纯粹的蟒蛇引用模块留在周围（而且，确实，我希望他们能够_poliferate_，或许在某些时候采用一些pypy家伙的工作;）。
也许这些东西的标准版本可以用PyPy下的RPython编写，所以他们会编译成快速的机器代码，然后那些C版本就不会了被需要。但是对于CPython，我认为我们需要
C版本。
无论如何，C版本是受欢迎的，我只是不想丢失
Python版本（并通过重新编码使它们的可读性降低
RPython中的
会干扰教学使用）。
Alex
I''ve always found the string-building idiom
temp_list = []
for x in various_pieces_of_output():
v = go_figure_out_some_string()
temp_list.append(v)
final_string = ''''.join(temp_list)
completely repulsive. As an alternative I suggest
temp_buf = StringIO()
for x in various_pieces_of_output():
v = go_figure_out_some_string()
temp_buf += v
final_string = temp_buf.getvalue()
here, "temp_buf += v" is supposed to be the same as "temp_buf.write(v)".
So the suggestion is to add a __iadd__ method to StringIO and cStringIO.
Any thoughts?
Also, I wonder if it''s now ok to eliminate the existing StringIO
module (make it an alias for cStringIO) now that new-style classes
permit extending cStringIO.StringIO.
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
...temp_buf = StringIO()
for x in various_pieces_of_output():
v = go_figure_out_some_string()
temp_buf += v
final_string = temp_buf.getvalue()
here, "temp_buf += v" is supposed to be the same as "temp_buf.write(v)".
So the suggestion is to add a __iadd__ method to StringIO and cStringIO.
What''s the added value of spelling x.write(v) as x += v? Is it worth
the utter strangeness of having a class which allows += and not + (the
only one in the std library, I think it would be)...?
Any thoughts?
I think that the piece of code you like and I just quoted is just fine,
simply by changing the += to a write.
Also, I wonder if it''s now ok to eliminate the existing StringIO
module (make it an alias for cStringIO) now that new-style classes
permit extending cStringIO.StringIO.
I love having a pure-Python version of any C-coded standard library
module (indeed, I wish I had more!-) for all sorts of reasons, including
easing the burden of porting Python to weird platforms. In StringIO''s
case, it''s nice to be able to use the above idiom to concatenate Unicode
strings just as easily as plain ones, for example -- cStringIO (like
file objects) wants plain bytestrings.
It would be nice (in Py3k, when backwards compatibility can be broken)
to make the plain-named, "default" modules those coded in C, since
they''re used more often, and find another convention to indicate pure
Python equivalents -- e.g., pickle/pypickle and StringIO/pyStringIO
rather than the current cPickle/pickle and cStringIO/StringIO. But I
hope the pure-python "reference" modules stay around (and, indeed, I''d
love for them to _proliferate_, maybe by adopting some of the work of
the pypy guys at some point;).
Alex
al***@mail.comcast.net (Alex Martelli) writes:What''s the added value of spelling x.write(v) as x += v? Is it worth
the utter strangeness of having a class which allows += and not + (the
only one in the std library, I think it would be)...?
Sure, + can also be supported. Adding two StringIO''s, or a StringIO to a
string, results in a StringIO with the obvious contents.
In StringIO''s case, it''s nice to be able to use the above idiom to
concatenate Unicode strings just as easily as plain ones, for
example -- cStringIO (like file objects) wants plain bytestrings.
I wasn''t aware of that limitation--maybe cStringIO could be extended
to take Unicode. You''d use an encode or decode method to get a
bytestring out. Or there could be a mutable-string class separate
from cStringIO, to be used for this purpose (of getting rid of the
list.append kludge).
But I hope the pure-python "reference" modules stay around (and,
indeed, I''d love for them to _proliferate_, maybe by adopting some
of the work of the pypy guys at some point;).
Maybe the standard versions of some of these things can be written in
RPython under PyPy, so they''ll compile to fast machine code, and then
the C versions won''t be needed. But with CPython I think we need the
C versions.
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
...In StringIO''s case, it''s nice to be able to use the above idiom to
concatenate Unicode strings just as easily as plain ones, for
example -- cStringIO (like file objects) wants plain bytestrings.
I wasn''t aware of that limitation--maybe cStringIO could be extended
to take Unicode. You''d use an encode or decode method to get a
bytestring out.
But why can''t I have perfectly polymorphic "append a bunch of strings
together", just like I can now (with ''''.join of a list of strings, or
StringIO), without caring whether the strings are Unicode or
bytestrings?
Or there could be a mutable-string class separate
from cStringIO, to be used for this purpose (of getting rid of the
list.append kludge).
StringIO works just fine. Developing (and having to document, learn,
teach, ...) a separate interface just in order to remove StringIO does
not seem worth it. As for extending cStringIO.write I guess that''s
possible, but not without breaking compatibility (code that now uses
that write with unicode strings assuming that they''ll get encoded into
bytestrings by the default encoding, and similarly assumes that getvalue
always returns a bytestring, when called on a cStringIO instance); you''d
need instead to add another couple of methods, or wait for Py3k.
But I hope the pure-python "reference" modules stay around (and,
indeed, I''d love for them to _proliferate_, maybe by adopting some
of the work of the pypy guys at some point;).
Maybe the standard versions of some of these things can be written in
RPython under PyPy, so they''ll compile to fast machine code, and then
the C versions won''t be needed. But with CPython I think we need the
C versions.
By all means, the C versions are welcome, I just don''t want to lose the
Python versions either (and making them less readable by recoding them
in RPython would interfere with didactical use).
Alex
这篇关于StringIO提案：添加__iadd__的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
