A Python API function "PyFile_OpenFile()" would also solve this issue, but obviously that wouldn't exist in 2.3 or earlier, so doesn't help this specific case.
According to Martin von Loewis, this is a lost cause - mixing runtimes is never OK, even if you don't use "dangerous" functions (like ones which use FILE*). However, in practical terms, I've never generated a problem (although I haven't tried very hard).
Yes, hence I never pursued it. "Although practicality beats purity" seems to apply, but I don't care enough to push it.
Does the move to VC7 mean that we'll break this strategy with Python 2.4 distutils ?
Yes, unless we do as outlined in my mail.
I may be misunderstanding what is being discussed here, but I believe that with the move to VC7, you will need the following to build extensions compatible with both Python 2.3 and 2.4:
1. Installed copies of both Python 2.3 and 2.4. 2. EITHER MSVC 6 and 7 (both versions) OR mingw
Yes, that is true for all practical intent, if your installation has extension modules. However, for a pure-python distribution, you need *no* compilers installed. In that case, we still have a problem - at the moment, the installation is guaranteed to fail for either Python 2.3 and before, or for 2.4, depending on which CRTL was used to build wininst.exe. To clarfify, I am talking about only how wininst.exe interacts with Python, not extension building related issues (even though they are similar). Mark.