M.-A. Lemburg wrote:
>  I don't see a good solution for these other than introducing
>  a set of new APIs (and maybe doing some macro magic as Martin
>  did for PyArg_ParseTuple()). Due to the fact that changes in
>  the types of output parameters require changes in the
>  extension variable type layout itself, they introduce a large
>  number of type changes in the extension and make writing
>  backwards compatible extensions harder than necessary.

That's not true. It is very easy to write extensions that
receive such values and are still backwards-compatible.

Suppose you had

  int pos;
  PyObject *k, *v;

  PyDict_Next(dict, &pos, &k, &v);

You just change this to

  /* beginning of file */
  #ifdef Py_HEX_VERSION < 2.5
  typedef int Py_ssize_t;
  #endif

  /* later */
  Py_ssize_t pos;
  PyObject *k, *v;

  PyDict_Next(dict, &pos, &k, &v);

That's it!

>  Furthermore, all extensions for Python 2.4 would have to be
>  ported to the new Python API and porting is not going to
>  be a simple recompile, but will require C skills.

Not all extensions. Only those that call functions that expect
int* output parameters - which is fairly uncommon.

>  Martin, please add the above points to the PEP. I'd also
>  like to see it published, because it's hard to track a PEP
>  in the mailing

It's very difficult to get a PEP number assigned. I wrote
peps@[...].org with no response.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@[...].org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.c
om