RetroSearch Browse

Tue Jan 10 21:28:43 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-January/059601.html

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 at python.org with no response.

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-January/059601.html below:

[Python-Dev] New PEP: Using ssize_t as the index type