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

M.-A. Lemburg mal at egenix.com
Fri Mar 17 21:49:09 CET 2006

Martin v. Löwis wrote:

M.-A. Lemburg wrote:

I think it's only fair that I ask the patch authors to complete the PEP, since the ssizet patch is causing extension authors enough trouble already. Well, the PEP is complete as it stands. It's possible to provide more guidelines, but the specification part of it says precisely what I intend it to say. Also, the API documentation ought to be in the Python documentation, and, for these changes, it is.

Changes to the public API must be documented somewhere, either in Misc/NEWS or in the PEP. How else do you expect users to find out about these changes ???

If you want quick adoption of the changes, you have to make it as easy as possible for the authors to port their extensions to the new API. Otherwise, we'll end up having quite a large number of users who can't switch to Python 2.5 simply because their favorite extensions don't work with it. I don't see how giving a complete list of all changed functions helps in any way.

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 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.

Again, if you don't make it easy for the developers, they are going to have a hard time upgrading their modules and getting them stable again after the changes. Telling them to read the header files or API docs and suggesting that they should compare 2.4 and 2.5 versions of these should not be the attitude with which such changes are approached.

It's also not good enough to simply suggest to ignore compiler warnings - this falls back on the extension authors and the quality of their code without them really having done anything wrong. Sure. Compiler warnings should be corrected. That's why the compiler emits them. However, I don't see how this is related to the text of the PEP.

""" 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 ?

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Mar 17 2006)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the Python-Dev mailing list