[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