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

["Martin v. Löwis"]

Michael P. Soulier wrote:
> On 21/03/06 Neil Schemenauer said:
> 
>> 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?
> 
> Can the old API stay around for a while? There's little to anger users more
> than API changes that aren't backwards compatible. 

The changes Neil mention do not necessarily to involve API changes.
For example:

Use unions for PyObject structure  (allowing strict aliasing
by the compiler).

   I don't think it this is really necessary, perhaps Neil
   meant "use struct inheritance" instead, where you have

   typedef struct _object{
     Py_ssize_t ob_refcnt;
     struct _typeobject *ob_type;
   } PyObject;

   typedef struct _var_object{
     PyObject ob;
     Py_ssize_t ob_size;
   } PyVarObject;

   typedef struct {
     PyVarObject ob;
     long ob_shash;
     int ob_sstate;
     char ob_sval[1];
   } PyStringObject;

   So, to access ob_refcnt when given a PyStringObject*o,
   you currently could write

      o->ob_refcnt

   and, in P3yk, you would write

      o->ob.ob.ob_refcnt

   However, this isn't really an API change: You don't access
   ob_refcnt *anyway*. Instead, you write Py_INCREF and Py_DECREF,
   and these continue to work, with Py_INCREF being defined as

   #define Py_INCREF(o) (((PyObject*)o)->ob_ref++)

   Now, there are slight details, such as access to ob_type. We could
   introduce a Py_OB_TYPE macro that gives access to ob_type across
   versions, likewise Py_OB_SIZE.

Other changes Neil mentioned would be API changes, e.g. dropping
sq_concat.

Yet other changes might be unimplementable, e.g. "Move GC attributes
into the PyObject structure": where would you place ob_size if
both are present, and how would code deal with ob_size and/or these
fields being at different offsets?

So it must be considered on a case-by-case basis. Making a general
promise that the old API could be maintained in all cases misses
the point of Python 3.

Regards,
Martin