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

[Stephen J. Turnbull]

Tony Kelman writes:

 > If potential contributors have a desire to get it working in the
 > first place, then they will also be invested in helping keep it
 > working on an ongoing basis.

Sure -- as long as it works for them, though, such potential
contributors don't necessarily care if it works for anybody else.  My
experience (in other projects) is that allowing that level of
commitment to be sufficient for inclusion in the maintained code base
frequently results in bug reports from third parties who try to use
the new feature and discover it *doesn't* work for them.  The core
maintainers then have a very unpleasant choice: to say "we don't
support that usage", or to deal with the problem on a continuing basis
(because the same issues tend to regress repeatedly as the said
"invested contributors" continue to modify their code on the same
"works for us" basis).

 > If that's how it's seen at this point, then it sounds like the
 > logical course of action for CPython-with-MinGW is to demonstrate
 > feasibility in a fork. Get what currently works as a set of
 > 80-something patches and PKGBUILD instructions into a single
 > repository that is usable by a wider variety of people, in more
 > distributions, etc. Set up as much CI as possible so every patch
 > gets tested in as many configurations as we can.  Experiment with
 > extension compatibility and find out what is actually achievable,
 > with or without needing to modify MinGW-w64 in the process.

Sounds good to me.  You seem to think that's excessive, though:

 > There are people, though evidently not much of python-dev, who have a
 > need and desire to make this happen.

Well, for starters, most of python-dev would rather avoid any contact
whatsoever with Windows.  I think part of the problem is that Windows
developers *of* Python are *very* rare (fingers of one hand rare).
Sure, there are many Windows-based Python developers, and quite of few
of them do a fair amount to contribute to Python on Windows -- but
they do that work in *Python*, not at a level where they deal with the
extension ABI.  Even those who do work on C extensions have so far
been happy to work with the VC build (except for the recurrent issue
of getting one's hands on the toolchain).

So why should python-dev have a desire to do that work?  It should be
evident by now that our belief is that the large majority of Windows
users is well-served by the current model (produce an official binary
and a plethora of compatible extensions, which provides strong
incentive to third parties to ensure that their extensions and
alternative builds of core are also compatible).

I think the repeated query, "why isn't this model good enough for
you?" is being misinterpreted.  I suppose that some who ask that
really want to know, because if you have what they consider a good
reason, they'd be willing to help.  Others are asking but by "you"
they mean the world at large, in particular, "what benefit is there to
the large number of users well-served by the current model?"

 > It seems python-dev would rather have us spend zero time proposing
 > changes that allow CPython itself to be built differently than
 > today, and all of our time on MinGW extensions.

Of course they would.  (Third person because I'm not competent to do
the work anyway.)  It's quite clear that one thing the two sides agree
on is that ensuring that MinGW and VC interpreter and extension builds
can mix and match is quite a bit of work.  They quite naturally don't
want to do that work, and don't see much point in discussing it if the
(apparently) few people who need it aren't going to supply the
resources.

That's quite a reasonable solution, really: *both* communities avoid
spending effort on mix and match, and because it's a fork, it's a
different name, and people won't expect them to mix and match.

 > I personally find 3 of the 4 combinations of how one could build
 > CPython and how one could build extensions interesting and worth
 > looking into for different reasons (the one that's uninteresting to
 > me is the currently used all-MSVC method, due to its many
 > limitations I listed earlier).  Ray for example may only care about
 > using MinGW for everything. Python's a big community with lots of
 > room for different people to work on different aspects of the same
 > set of problems.

There's a reason we call it "core".  One of python-dev's more
important responsibilities is to ensure that the "aspects" work and
play well together.  "Aspects" people tend to deprecate that
responsibility (until somebody else's "aspect" treads on their blue
suede shoes).  That's as it should be, IMO -- but so is python-dev's
reluctance to admit new "aspects" until their impact on core
responsibilities is made clear.