On Tue, Jun 22, 2010 at 11:17 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
(2) Data sources.<br>
<br>
These can be functions that produce new data from non-string data,<br>
e.g. str(<int>), read it from a named file, etc. An example is read()<br>
vs. write(): it's easy to create a (hypothetical) polymorphic stream<br>
object that accepts both f.write('booh') and f.write(b'booh'); but you<br>
need some other hack to make read() return something that matches a<br>
desired return type. I don't have a generic suggestion for a solution;<br>
for streams in particular, the existing distinction between binary and<br>
text streams works, of course, but there are other situations where<br>
this doesn't generalize (I think some XML interfaces have this<br>
awkwardness in their API for converting a tree to a string).<br></blockquote></div><br>This reminds me of the optimization ElementTree and lxml made in Python 2 (not sure what they do in Python 3?) where they use str when a string is ASCII to avoid the memory and performance overhead of unicode. Also at least lxml is also dealing with the divide between the internal libxml2 string representation and the Python representation. This is a place where bytes+encoding might also have some benefit. XML is someplace where you might load a bunch of data but only touch a little bit of it, and the amount of data is frequently large enough that the efficiencies are important.<br clear="all">
<br>-- <br>Ian Bicking | <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>