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

[Kevin Jacobs <jacobs@bioinformed.com>]

Hi Neil,

I've been fairly quiet on the Python-dev front for a while -- mainly because
I use Python every day and it almost always works.  However, as someone who
regularly writes small C extension modules and types, I would certainly add
a vote for sacrificing any vestiges of backward compatibility in order to
rationalize the PyObject structure.  The relative short-term pain of forward
porting my code base is far offset by the long-term gains of having a
legacy-free and streamlined structure.  Put another way, forward porting
code is less work than continuing to write code long-term against the
current model.

Two important disclaimers: 1) For my purposes, I don't need code that runs
on both Python pre-3k and post-3k without change.  2) I have the ability and
means to forward port my code and the necessary third-party extensions that
I'll need.  Many other developers and users will not have this luxury.

-Kevin


On 3/21/06, Neil Schemenauer <nas at arctrix.com> wrote:
>
> On Tue, Mar 21, 2006 at 05:01:31PM +0100, Thomas Wouters wrote:
> > I would like Pythonic code to be usable in both 2.x (where x is,
> > say, 6 or higher) and 3.0, but 3.0 shouldn't need to worry too
> > much about it.
>
> 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?
>
> Some possible areas of cleanup:
>
>     * Use unions for PyObject structure (allowing strict aliasing
>       by the compiler).
>
>     * Move GC attributes into the PyObject structure (e.g. similar
>       to how ob_size works).
>
>     * Rethink weakref implementation (not sure about details but
>       maybe we can do better).
>
>     * Rationalize method structures (e.g. sq_concat and sq_repeat
>       could go away since we can use nb_add and nb_multiply).
>
>     * Rationalize finalizer behavior (e.g. get rid of __del__
>       methods in favor of guardians?).
>
>     * Make it easier to write simple extension types.  For example,
>       there could be standard tp_clear and tp_traverse methods that
>       could work if the object is simply an array of PyObject pointers.
>
>     * Do we still need tp_print and tp_repr?
>
>     * Register instead of stack based VM?
>
>
> 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.
>
>   Neil
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/jacobs%40bioinformed.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060321/36e8b341/attachment.htm