On 8/25/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > the fact that it's *impossible* to offer a view subtype that's com- > > patible with the current PyString C API might be an issue, though. > > what's the current thinking wrt. the PyString C API, btw. has any of the > various bytes/wide string design proposals looked at the C API level ?
No... I was hoping to get to that but ended up spending unanticipated time on fixing comparisons. Maybe the first step ought to be similar to what was done for int/long unification -- keep both the PyString_ and PyUnicode_ APIs around but make the PyString_ APIs do whatever they do on Unicode objects instead. Each use of certain macros will still have to be patched, obviously; e.g. a common way to create a string is to call PyString_FromStringAndSize(NULL, nbytes) and then to call something like memcpy(PyString_AS_STRING(obj), source, nbytes) -- this won't work of course. There are a bunch of PyBytes_ APIs that can be used in those places where 8-bit strings are really used to hold binary data, not characters. These have been modeled on the PyString APIs (even with AS_STRING and GET_SIZE macros). See Include/bytesobject.h. -- --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/archive%40mail-archive.com
