> Why not [require administrative privileges]?

Because some people want to use Python and don't have administrative permissions on their own machine (e.g. students, employees, researchers, etc.)

> The standard approach is to rebuild extension for every minor
> release, since the standard Python ABI is not guaranteed to stay
> backwards compatible.

The last point I posted lets you rebuild extensions *with a different compiler*. So when you upgrade to VC15 you can use that to build your Python 3.5 extensions instead of VC14, and still ship those extensions to users without requiring them to install the VC15 redist. Static linking is part of this

> the fact that you have to reinstall
> Python and all extensions in case there's some bug in the CRT is really
> the main argument against doing static linking.

The same argument applies against app-local copies of the runtime, which is why I'm trying to avoid these dependencies rather than volunteering to redistribute and update them for all extensions.

Also, we already rebuild and release Python due to bugs in OpenSSL, so I see no reason why we wouldn't do the same for bugs in the (small) part of the CRT we statically link.

> Static linking of the CRT is normally only used in situations where
> you don't want to have single file executables without external
> dependencies, e.g. for working on arbitrary Windows systems without
> having to install anything. It's a valid use case, but not a general
> purpose one.

Normally, yes, but we have a new use case now that the majority of the C runtime is preinstalled on machines and versionless.

> What's the advantage of using /MT when you then add
> all of the CRT libs to the set of libs which are dynamically linked ?

The part that is statically linked is only a few functions that are either critical to program initialization or specially optimized by the compiler, and the rest of the CRT is versionless and managed by the operating system.

To be clear, the DLLs I listed are not required by CPython or most pure-C extensions (including, I assume, cffi and Cython). It's only when you start using C++ and especially the Microsoft provided libraries for parallelism that you need these DLLs.

> If I want to ship a C extension compiled for Python 3.5 which links to an
> external DLL on the system, I will have to tell the users of the extension
> to first run VCredist in order for them to be able to use extension
> on their system, since Python 3.5 will not ship with the necessary
> CRT DLLs, correct ?

Correct, just as it's always been. However, if you want to ship a C extension compiled for Python 3.5 which *does not* link to an external DLL, you *do not* have to tell your user to install anything.

> includes getting CRT bug fixes by means of OS updates rather than complete
> reinstalls of Python and all your extensions.

Users of Python 3.5 will get CRT updates from the OS. Only a few trivial functions are statically linked under this scheme.

> Developers can work around these things, but if we end up requiring them
> to redistribute VCredist with every single package that has external
> dependencies, just to be able to install a binary package,
> because Python itself doesn't ship the necessary DLLs, then something
> is clearly broken for Python on Windows.

> Alternatively, we tell users to install VCredist by hand in case
> they plan to use Python with C extensions. Possible, but not
> very user friendly either.

I proposed above making this an option in the installer. Problem is, it doesn't help extensions built with later compilers. Only the extension knows which version of the redist is needed.

> With Python 2.7 all this is not an issue, creating yet another road
> block to prevent upgrades :-(

The issue with Python 2.7 is that you need to use VC9. If you think requiring everyone to use VC14 for Python 3.5 forever is less of an issue than having to recompile static libraries with a new version of the compiler, please say so explicitly, as I have not heard anyone claim that and need to hear it said in complete seriousness before I have any chance of believing it's true.

> chances are high that this will not actually work out in
> practice. Backwards compatibility is already hard, forward
> compatibility is really really difficult to achieve without
> a time machine.

Agreed. However, the forward compatibility problem we're facing right now seems to be external libraries compiled under old compilers - that is, VC10 (to pick one example) failed at forward compatibility, and some work is required to fix that failure. If we concede defeat now, then we will also fail at forward compatibility, and it will take work in the future to correct our failure. I'm trying to do as much work now as I can to offset that work for everyone else later (and thanks for holding me accountable on this - it's more helpful than my apparently frustrated responses probably make it seem :) ).

> BTW: Do you know whether Python 3.5 will still work as Windows service
> without the MSVCR140 DLL available in the system folder ?

Yes, it will. MSVCR140 does not exist - it is called ucrtbase.dll and ships with Python 3.5, Windows 10, and (later this year, I'm told) through normal Windows updates for downlevel operating systems. This is the *only* part of the CRT (it's also the majority of the CRT) that we install, and we do force users to have administrative privileges when installing Python if they don't already have it.

Python does not depend on the C++ runtime. If an extension requires the C++ runtime, users will have to acquire it some other way.