Steve Dower <steve.do...@microsoft.com> wrote: > Is there some reason the Fortran part can't be separated out into a DLL?
DLL hell, I assume. Using the Python extension module loader makes it less of a problem. If we stick with .pyd files where everything is statically linked we can rely on the Python dev team to make sure that DLL hell does not bite us. Most of the contributors to projects like NumPy and SciPy are not computer scientists. So the KISS principle is important, which is why scientific programmers often use Fortran in the first place. Making sure DLLs are resolved and loaded correctly, or using stuff like COM or .NET to mitigate DLL hell, is just in a different league. That is for computer engineers to take care of, but we are trained as physicists, matematicians, astronomers, chemists, biologists, or what ever... I am sure that engineers at Microsoft could do this correctly, but we are not the kind of guys you would hire :-) OT: Contrary to common belief, there is no speed advantage of using Fortran on a modern CPU, because the long pipeline and the hierarchical memory alleviates the problems with pointer aliasing. C code tends to run faster then Fortran, often 10 to 20 % faster, and C++ tends to be slightly faster than C. In 2014, Fortran is only used because it is easier to program for non-specialists. And besides, correctness is far more important than speed, which is why we prefer Python or MATLAB in the first place. If you ever see the argument that Fortran is used because of pointer aliasing, please feel free to ignore it. Sturla _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
