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 [EMAIL PROTECTED] with no response. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
