[Python-3000] Last minute C API fixes

[M.-A. Lemburg]

On 2008-08-07 01:41, Guido van Rossum wrote:
> 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.

True, but isn't it better to go through that pain for a few extensions
now and then have a proper C API to use in 3.1 ? Otherwise, we end
up having to support those APIs for the whole lifetime
of the 3.x branch.

Note that those two APIs are not documented, so their use is not
yet officially allowed.

BTW: The correct way to get at an UTF-8 encoded version of a PyUnicode
object is to use PyUnicode_AsUTF8String() or the "s#" parser marker.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 07 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611