And for non-unicode inputs the code should use the PEP 3118 buffer API rather than PyBytes_ or PyString_ or whatnot.<br><br><div><span class="gmail_quote">On 10/26/07, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:guido@python.org">
guido@python.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2007/10/26, Bill Janssen <<a href="mailto:janssen@parc.com">
janssen@parc.com</a>>:<br>> I'm looking at the Py3K SSL code, and have a question:<br>><br>> What's the upshot of the bytes/string decisions in the C world? Is<br>> PyString_* now all about immutable bytes, and PyUnicode_* about
<br>> strings? There still seem to be a lot of encode/decode methods in<br>> stringobject.h, operations which I'd expect to be in unicodeobject.h.<br><br>I think the PyString encode/decode APIs should all go; use the
<br>corresponding PyUnicode ones.<br><br>I recommend that you write your code to assume PyBytes for<br>encoded/binary data, and PyUnicode for text; at some point we'll<br>substitute PyString for most cases where PyBytes is currently used:
<br>that will happen once PyString is called bytes in at the Python level,<br>and PyBytes will be called buffer. But that's still a while off.<br><br>--<br>--Guido van Rossum (home page: <a href="http://www.python.org/~guido/">
http://www.python.org/~guido/</a>)<br>_______________________________________________<br>Python-3000 mailing list<br><a href="mailto:Python-3000@python.org">Python-3000@python.org</a><br><a href="http://mail.python.org/mailman/listinfo/python-3000">
http://mail.python.org/mailman/listinfo/python-3000</a><br>Unsubscribe: <a href="http://mail.python.org/mailman/options/python-3000/greg%40krypto.org">http://mail.python.org/mailman/options/python-3000/greg%40krypto.org</a>
<br></blockquote></div><br>