Re: [Python-ideas] Create a StringBuilder class and use it everywhere
Ok, so while I think that cStringIO.StringIO is not what we shoud use, io.StringIO should be okay (since it wasn't explpicitly created to be file-like), so there's no reason not to use that (and it performs good, on pypy also) ((except that I don't like it's API, of course)). Thanks everyone! p.s.: it seems people read code much more often then they do read FAQ
On 2011-08-26, at 07:30 , k_bx wrote:
Ok, so while I think that cStringIO.StringIO is not what we shoud use, io.StringIO should be okay (since it wasn't explpicitly created to be file-like) It was. Hence its extending io.TextIOBase. io.StringIO is roughly the py3k version of StringIO.StringIO (when the latter was used with unicode strings)
k_bx writes:
Well, you are free to use StringBuilder in your own programs (though I don't recommend that).
p.s.: it seems people read code much more often then they do read FAQ
Sure, but that says more about the people than it does about the FAQ. We can't write all the code that they're going to read, and we can't choose what examples they'll follow. The best we can do is follow the Zen of Python, specifically, "There should be one -- and preferable only one -- obvious way to do it." (Don't say, "but the sep.join(lst) idiom is hardly obvious!" The Zen has an answer to that, too. Try "python -m this" if you don't know about the Zen.) The other ways of doing it are more specialized, ie, optimized for particular cases. The point is that the StringBuilder class doesn't do things any better than the existing idioms. Its only advantage is a somewhat more discoverable name. That's not a good enough reason to proliferate names for good ways to do this. And .join() is often natural, so it won't be deprecated in favor of StringBuilder.
On 2011-08-26, at 07:30 , k_bx wrote:
Ok, so while I think that cStringIO.StringIO is not what we shoud use, io.StringIO should be okay (since it wasn't explpicitly created to be file-like) It was. Hence its extending io.TextIOBase. io.StringIO is roughly the py3k version of StringIO.StringIO (when the latter was used with unicode strings)
k_bx writes:
Well, you are free to use StringBuilder in your own programs (though I don't recommend that).
p.s.: it seems people read code much more often then they do read FAQ
Sure, but that says more about the people than it does about the FAQ. We can't write all the code that they're going to read, and we can't choose what examples they'll follow. The best we can do is follow the Zen of Python, specifically, "There should be one -- and preferable only one -- obvious way to do it." (Don't say, "but the sep.join(lst) idiom is hardly obvious!" The Zen has an answer to that, too. Try "python -m this" if you don't know about the Zen.) The other ways of doing it are more specialized, ie, optimized for particular cases. The point is that the StringBuilder class doesn't do things any better than the existing idioms. Its only advantage is a somewhat more discoverable name. That's not a good enough reason to proliferate names for good ways to do this. And .join() is often natural, so it won't be deprecated in favor of StringBuilder.
participants (3)
-
k_bx -
Masklinn -
Stephen J. Turnbull