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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com