[Python-Dev] Status of C compilers for Python on Windows

[Steve Dower]

DLLs linked by import library at compile time (ie. not using LoadLibrary calls) and placed in the same directory as the .pyd should be exempt from DLL hell - Python already creates an activation context when importing pyds to let them load their own dependencies. Multiple CRTs are also okay as long as they don't try and share state (such as file descriptors) across boundaries.

I do understand the lack of knowledge and experience though. I've helped out in the past but I personally don't have the bandwidth to contribute more, nor the persuasiveness to get someone else to.

Top-posted from my Windows Phone
________________________________
From: Sturla Molden<mailto:sturla.molden at gmail.com>
Sent: ‎10/‎11/‎2014 9:59
To: python-dev at python.org<mailto:python-dev at python.org>
Subject: Re: [Python-Dev] Status of C compilers for Python on Windows

Steve Dower <Steve.Dower at 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 at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141011/fe2f2f97/attachment.html>