Stephen J. Turnbull:
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.
Good point. I definitely care whether patches work for everyone else. Patches should be done well and accompanied with proper documentation so new functionality is fully reproducible. If that's what's holding up review, comments in the bug threads indicating as much would be helpful. Any fork will also have to be thoroughly documented if it's to have any chance of working.
Sounds good to me. You seem to think that's excessive, though:
No, just hearing the words come out of my mouth they sound a little nuts. Maybe not, there are after all half a dozen or more incompatible alternate Python implementations floating around. I think most of them started as from-scratch rewrites rather than source forks, but maybe that's irrelevant.
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).
In my opinion the MSVC toolchain makes that problem worse, as it's far harder for unix developers to have any familiarity with how things work. But you do have involvement and core developers from Microsoft which is obviously incredibly important. Maybe even mandatory for Python on Windows to be viable in your eyes.
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). It should be evident by now that our belief is that the large majority of Windows users is well-served by the current model
This is not the case at all in the scientific community. NumPy and SciPy put in a lot of extra work to come up with something that is compatible with the MSVC build of CPython because they have to, not because they're "happy to" jump through the necessary hoops. The situation today with NumPy AIUI is they already have to build with a custom hacked MinGW toolchain that only one person knows how to use. Evidently until very recently they were using a many-years-old 32-bit-only build of GCC 3.x. Do python-dev and numpy-discussion not talk to one another? I get that not everyone uses numpy, or Windows, but it sounds like there's very little understanding, or even awareness, of the issues they face.
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.
I'm going to move the "extensions with MinGW-w64" part of this conversation over to numpy-discussion, since they have a need for this today and are already using workarounds and processes that I don't think anyone is fully satisfied with. I do find this combination interesting, worth working on, and possible to make work well, but not completely in isolation as it does not address my embedding use case.
but so is python-dev's reluctance to admit new "aspects" until their impact on core responsibilities is made clear.
Okay. I'll table the discussion with python-dev for now then. -Tony _______________________________________________ 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
