Patch 592529: Split-out ntmodule.c
I'm collecting opinions on whether the module nt should live in its own source code file; it currently lives in posixmodule.c. http://python.org/sf/592529 has a patch that implements that feature. Tim is -0, Guido is +0.5, more votes are needed. 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? Regards, Martin
On 9 Aug 2002, Martin v. [iso-8859-15] L�wis 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
participants (2)
-
Andrew MacIntyre
-
loewis@informatik.hu-berlin.de