Martin v. Löwis: > The problem (for me, atleast) is that VC is so much more convenient to > work with.
In my experience Visual C++ has always produced faster, more compact code than Mingw. While this may not be true with current releases, I'd want to ensure that the normal Python download for Windows didn't become slower. Visual C++ 2005 includes profile guided optimization (although this is not included in the Express Edition) and it would be interesting to see how much of a difference this makes. Microsoft was willing to give some copies of VS to Python developers before so I expect they'd be willing to give some copies of VS Professional or Team System. Tim Delaney: > There was a considerable amount of angst with the 2.4 release that can be > blamed solely on the CRT change (and hence different DLLs to link to). And > with them deprecating ISO standard functions ... One solution to CRT change is to drop direct linking of modules to the CRT and vector them through the core DLL. The core PythonXX.DLL would expose an array of functions (malloc, strdup, getcwd, ...) that would be called by all modules indirectly. Then, it no longer matters which compiler version or compiler you build extension modules with. Its quite a lot of work to do this as each CRT call site needs to change or a well thought through macro scheme be developed. Paul Moore: > The project file conversions seemed to go fine, and the debug builds > were OK, although the deprecation warnings for all the "insecure" CRT > functions was a pain. It might be worth adding > _CRT_SECURE_NO_DEPRECATE to the project defines somehow. I haven't tried to build Python with VC++ 2005 yet, but other code has also required _CRT_NONSTDC_NO_DEPRECATE for some of the file system calls. Neil _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
