[Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Fri Mar 17 23:16:45 CET 2006

M.-A. Lemburg wrote:

Changes to the public API must be documented somewhere, either in Misc/NEWS or in the PEP.

Sure. They are documented in the PEP, which says

All occurrences of index and length parameters and results are changed

to use Py_ssize_t, including the sequence slots in type objects, and

the buffer interface.

The relevant Misc/NEWS entry is

It documents those changes, allows extension authors and extension users to check their extensions for possible problems and is (or at least should be) standard procedure.

The changes are documented in the PEP. The current API is documented in the API docs.

The list of changes is also necessary in order to be able to write code which allows a module to work in both Python 2.4 and 2.5. The code snippet that Thomas suggested should be part of the conversion guidelines.

It is (atleast some form of it).

""" Module authors have the choice whether they support this PEP in their code or not; if they support it, they have the choice of different levels of compatibility.

If a module is not converted to support this PEP, it will continue to work unmodified on a 32-bit system. On a 64-bit system, compile-time errors and warnings might be issued, and the module might crash the interpreter if the warnings are ignored. """ Do you really think module authors do have a choice given that last sentence ?

I really do. Most developers will not be confronted with 64-bit systems for several years to come. That current hardware supports a 64-bit mode is only one aspect: Most operating system installations on such hardware will continue to operate in 32-bit mode for quite some time.

Of course, developers of widely-used extension modules will need to support the PEP in some way. They should follow the guidelines in the PEP.

Regards, Martin

More information about the Python-Dev mailing list