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

[M.-A. Lemburg]

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 ssize_t 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 ! ::::