On Wed, Aug 6, 2008 at 3:40 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2008-06-11 16:32, M.-A. Lemburg wrote: >> >> There are two things I'd like to get in to 3.0: >> >> * .transform()/.untransform() methods (this is mostly done, just need >> to add the methods to PyUnicode, PyBytes and PyByteArray) >> >> * cleanup of the PyUnicode_AsString() and PyUnicode_AsStringAndSize() >> C APIs (these APIs don't fit into the naming scheme used in the >> Unicode API and have a few other issues as well, see issue 2799; >> at the very least they should be made interpreter internal, ie. >> rename them to _PyUnicode_AsString() and _PyUnicode_AsStringAndSize() >> to prevent their use in extensions) > > As it turned out, I haven't had time to look into these things. > > The .transform()/.untransform() can wait until 3.1. The codecs module > allows doing same-type conversion, so that can be used as work-around.
Fine (obviously). > Regarding the C API, I would really not like extensions to start using > these APIs since they expose internals that should be exposed in this > direct way (PyUnicode_AsString()) and/or behave differently than the > corresponding PyString API (PyUnicode_AsStringAndSize()). > > Since I don't have time to work on the C API, I'd like to do a > simple name change to make them private to the interpreter. > > Is it too late for that ? That kind of depends on how far other 3rd party projects are in porting their extensions to Py3k, and how much they've bought into these APIs. I recall that mechanically translating these APIs to something else can easily introduce memory leaks. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
