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