This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients cgohlke, larry, lemburg, paul.moore, steve.dower, tim.golden, zach.ware
Date 2015-08-17.08:14:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 15.08.2015 22:41, Steve Dower wrote:
> Marc-Andre: there are a few concerns with including DLLs that aren't new with any of the 3.5 changes.
> * depending on another CRT version is fine *if* it is available (users may have to be told/helped to install the redistributable themselves)
> * CRT state will not be shared between versions. This is most obviously a problem if file descriptors are shared, but may also appear when writing console output, doing floating-point calculations, threading, and memory management.
> * potentially many more issues if C++ is used, but since Python doesn't use C++ this is mainly a concern where you have two DLLs using C++ and different runtimes (the CRT is partially/fully implemented in C++, so issues may theoretically occur with only one DLL using C++, but I'm yet to see any in practice or even identify any specific issues - maybe it's fine? I'm not going to guarantee it myself)

These issues have always existed in the past, but were never a real
problem, AFAIK, since the libraries intended to be used externally
will typically come with e.g. memory management APIs to make sure
they retain ownership of the allocated memory on their heap.

It is quite natural to have to run VCredist as part of an application
installer to make sure that the target system has the right VC runtime
DLLs installed (and the installer will do the checking).

The purpose of having DLLs for the runtime is to reduce overall
size of the components as well as being able to easily address
bugs and security issues in the runtime DLLs *without* having
to recompile and redeploy all components using them.

By forcing or even suggesting statically compiled Python C extensions,
we would break this goal and potentially put our users at risk.

IMO, we should follow the MS recommendations for "Deployment in Visual C++"
as we did in the past:

You can statically link a Visual C++ library to an application—that is, compile it into the
application—so that you don't have to deploy the Visual C++ library files separately. However, we
caution against this approach because statically linked libraries cannot be updated in place. If you
use static linking and you want to update a linked library, you have to recompile and redeploy your

Perhaps I'm missing something, but if the only advantage of statically
compiling in the runtime is to have users not need to run VCredist
at install time, it's not worth all the added trouble this introduces.

If you are trying to make it possible to compile extensions with
compilers following VC2015, then I also don't think this approach
will work: the new compilers will use a new runtime and so
issues you describe above come into play between the extensions
and the interpreter.

In that scenario, they will create real problems, as far as I
understand, the since the Python C API expects to be able to e.g.
share FDs, internal state such as which locale to assume, or
use and free memory allocated by either the interpreter or the
extension in the resp. other component (e.g. PyArg_ParseTuple()).

So in the end, you'll still have to use the same compiler for
extensions as the one used for compiling CPython to make sure
you don't run into these issues - which is essentially the same
situation as for Python <=3.4.
Date User Action Args
2015-08-17 08:14:44lemburgsetrecipients: + lemburg, paul.moore, larry, tim.golden, cgohlke, zach.ware, steve.dower
2015-08-17 08:14:44lemburglinkissue24872 messages
2015-08-17 08:14:42lemburgcreate