[Python-3000] C API changes? [Was: Python 3000 Process]
Kevin Jacobs <firstname.lastname@example.org>
bioinformed at gmail.com
Tue Mar 21 20:23:36 CET 2006
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
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.
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.
> Python-3000 mailing list
> Python-3000 at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000