[SciPy-Dev] win32 binaries and scipy 0.17.0 release

[Nathaniel Smith]

On Sat, Jan 2, 2016 at 2:04 PM, Tony Kelman <tony at kelman.net> wrote:
> Nathaniel Smith <njs <at> pobox.com> writes:
>
>> It's also true though that the userbase who cares about running
>> numpy inside a non-standard embedded python is much, much smaller
>> than the userbase trying to run numpy on standard python. We
>> certainly care about all users, but we also have to prioritize,
>> and have extremely limited resources. :-/
>
> Sure. I didn't mean to imply that building CPython itself with
> MinGW-w64 was solely useful for the embedded use case. In fact the
> MSYS2 build of CPython works *today* with Python 3.5, NumPy, SciPy,
> etc. which cannot be said of any other Windows builds of SciPy using
> freely available compilers. "Standard python" doesn't have to mean
> "downloaded from python.org" if the users' needs are met, one way or
> another. I don't think the users who download Python and the
> scientific stack via Anaconda care much about the details of how
> it's built, as long as they can get the packages they need to work.

That's all great until the msys2 users type "pip install psycopg2" and
pip happily installs a package that was built against the standard
windows cpython ABI, and breaks in obscure ways when used from msys2
python. My feeling is that while there are some users who might be
happy with treating anaconda or whatever like a walled garden and
never going outside a small curated set of packages, for most users
what they want is the full python ecosystem. And that means
interoperating with that ecosystem. Even if parts of it can sometimes
be very frustrating to work with :-).

>> It's possible that over the next few years enough patches will
>> materialize and things will settle down enough to allow the
>> programs mentioned above to switch to a MSVC2015-compatible
>> runtime+ABI, which would at least allow them to embed a standard
>> py35. Fingers crossed.
>
> I'm not sure that adds much value to all that many projects. If
> you already prefer MinGW-w64 over MSVC (2015 still hasn't solved
> inline assembly, Fortran, C99 complex numbers, or use with autotools),
> there's little benefit to the 2015 runtime.

Depends on whether you care about python or not :-). Also one might
reasonably want to get off of the 10 year old msvcrt.dll runtime even
without caring about MSVC, but YMMV. And I guess there are some
weirdos out there who actually like using Visual Studio to write
extension code :-). (I can't seem to find the numbers right now, but
apparently PTVS gets a ton of downloads.)

In any case, the point is just that mingw-w64 itself may well switch
to an MSVC-compatible configuration as the main supported target over
the next while.

> In Julia's case the most
> likely path forward towards "MSVC compatibility" doesn't involve MSVC
> at all, it will use Clang for C and C++ and the PGI-donated LLVM
> Fortran front end (https://www.llnl.gov/news/nnsa-national-labs-team-
> nvidia-develop-open-source-fortran-compiler-technology) once that's
> available. I'm sure LLVM will need some assistance in making that
> compiler support Windows once it gets open-sourced, but that's not
> expected until "late 2016" so it doesn't help solve SciPy's short term
> problems. It's on my personal radar though, and it may be worth keeping
> yon yours as well.

I hadn't seen that Fortran announcement -- that is indeed interesting.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org