[Python-3000] Last minute C API fixes

Guido van Rossum guido at python.org
Thu Aug 7 01:41:59 CEST 2008


On Wed, Aug 6, 2008 at 3:40 PM, M.-A. Lemburg <mal at egenix.com> 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/)


More information about the Python-3000 mailing list