[Python-3000] C API changes? [Was: Python 3000 Process]

[Neal Norwitz]

On 3/21/06, Neil Schemenauer <nas at arctrix.com> wrote:
>
> The other question I haven't seen much discussion about is C API
> changes.  Are we hoping that people can port extension modules with
> little effort or are we going to be doing lots of cleanup?

Ideally both.  I started ripping out coerce.  I thought about
re-organizing all the methods to try to group them a bit better.  Then
I realized the beneift is likely far too small for the larger pain of
having to maintain 2 tables of methods (one for 2.x one for 3.x).  It
would be easier for extensions to conditionally not compile in the
nb_coerce method for 3.x.

I don't have any idea about the longer term.  It will be clearer where
we stand once we rip out all the cruft/backwards compatability.  Get
rid of old APIs, macros, etc.  At that point we should be in a better
position to determine how to proceed next.

I'm going to strive to rip out all the old stuff by the end of April,
but 2.5 should take higher priority.

> Some possible areas of cleanup:
>
>     * Use unions for PyObject structure (allowing strict aliasing
>       by the compiler).

Martin expanded on this one a bit.  We should do something so we don't
need -fno-strict-aliasing.

>     * Rethink weakref implementation (not sure about details but
>       maybe we can do better).

Sure, we should rethink everything IMO.  If we can't come up with
anything better, there's no work.

>     * Rationalize method structures (e.g. sq_concat and sq_repeat
>       could go away since we can use nb_add and nb_multiply).

Yes.

>     * Rationalize finalizer behavior (e.g. get rid of __del__
>       methods in favor of guardians?).

At least try to get rid of __del__.

>     * Make it easier to write simple extension types.

Yes.

>     * Register instead of stack based VM?

IMO this could go into 2.6, but definitely could be experimented in
3.x and backported.

> One part of me hopes that we could do a lot of cleanup in these
> areas.  Another part is concerned about badly breaking the huge
> number of extensions out there (a major reason for Python's success,
> IMO).  In any case, I hope an important objective of P3K will be to
> make writing extensions even easier.

Definitely.

n