[Python-Dev] Patch 592529: Split-out ntmodule.c

[Andrew MacIntyre]

On 9 Aug 2002, Martin v. [iso-8859-15] L=F6wis wrote:

> If you are familiar with the code, it would be good if you could
> comment on the following questions:
>
> - should os2module.c get its own source code file as well?
>
> - are the #ifdefs in the resulting ntmodule.c still needed?
>   I believe they are, as the various compilers appear to support
>   different sets of functions in their C libraries. Of course,
>   most of these could be eliminated if the C is avoided in favour
>   of the Win32 API. Alternatively, can anybody with access to any
>   of these compilers (BorlandC, Watcom, IBM) please comment on
>   which functions provided by MSVC are missing in those compilers?

I don't have a problem with the OS/2 stuff being split out as well.
However I think there is some merit to Tim's point (added as a comment to
the patch) about trying to contain the natural divergence of API support
if the code is completely split out.

I haven't looked at the your patch (just the SF patch manager
entry, sorry), but if a split is pursued, I would would find an approach
similar to the thread_* and dynload_* bits (in Python/) somewhat more in
keeping with the above reservation.

This approach would have a master module file (eg platformmodule.c) which
contains the init function and the PyMethodDef array (with methods
controlled by HAVE_method #ifdefs as appropriate), and includes
the platform specific implementation files.

I have had thoughts about doing this before, but the scale of the task and
the fact that I don't have a Windows dev box for testing put me off.

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au  | Snail: PO Box 370
        andymac@pcug.org.au            |        Belconnen  ACT  2616
Web:    http://www.andymac.org/        |        Australia