[Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0 (original) (raw)

M.-A. Lemburg mal at egenix.com
Wed May 28 14:59:33 CEST 2008


On 2008-05-28 14:29, Paul Moore wrote:

On 28/05/2008, M.-A. Lemburg <mal at egenix.com> wrote:

I'm beginning to wonder whether I'm the only one who cares about the Python 2.x branch not getting cluttered up with artifacts caused by a broken forward merge strategy. I care, but I struggle to understand the implications and/or what is being proposed in many cases.

Thanks, so I'm not the only :-)

Recent examples are the ABC backports and the current thread (string C API). I simply don't follow the issues well enough to comment.

How can it be that we allow major C API changes such as the renaming of the PyString APIs to go into the trunk without discussion or a PEP ? Christian has raised this a couple of times, but there has been little discussion. I suspect that this is because there is not enough clarity over the practical consequences. A PEP may help here, but I'm not sure how much - it could spark discussion, but would anyone actually end up any better informed?

Probably, yes.

The reason is that if you have a PEP, more people are likely to review it and make comments.

If you start a discussion with a general subject line which then results in lots of little sub-threads, important aspects of the discussion are likely to go unnoticed in the noise.

We're having lengthy discussions about the addition of single method to an object, but such major changes just go in like that and nobody seems to really care. I suspect deadline pressure and burnout are involved here. In all honesty, there's been little or no work done on the C API, which is just as much in need of review and possible cleanup for 3.0 as the language. It's as close as makes no difference to too late now - does that mean we've lost the chance?

Perhaps, but the C API is certainly not used by as many people as the Python front-end and changes to the C API also have much deeper consequences due the API being written in C rather than Python.

Overall, I don't think there's a lot to cleanup in the C API. Perhaps remove a few of those '...Ex()' APIs that were introduced to extend the original APIs and maybe remove or free up a few type slots that are no longer needed, but that's about it.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, May 28 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/


2008-07-07: EuroPython 2008, Vilnius, Lithuania 39 days to go

:::: 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


More information about the Python-Dev mailing list