Home Original page

[Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c

"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

- PEP 353: Using ssize_t as the index type.

> 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