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