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

[Nick Coghlan]

On 12 Oct 2014 04:20, "Steve Dower" <Steve.Dower at microsoft.com> wrote:
>
> 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.

The current key phrase in getting potential corporate sponsors interested
in the scientific Python stack is "big data analytics". The professional
programming world is actually quite bad at using modern mathematical
techniques effectively - the scientific community are way ahead of us.
Python is relatively unique in being a language used extensively by both
professional programmers *and* research scientists, so we're well
positioned to serve as a basis for effective communication between the two
groups.

AMPLab at Berkeley are one of the groups at the forefront of that. MS are
sponsors, so if you can find the group behind that sponsorship, you may
find folks in a position to help out with the scientific Python toolchain
challenges.

Cheers,
Nick.

>
>
> Top-posted from my Windows Phone
> ________________________________
> From: Sturla Molden
> Sent: ‎10/‎11/‎2014 9:59
>
> To: 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
>
> _______________________________________________
> 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/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141012/73406f47/attachment.html>