subprocess.py contains the following line (380 in CPython 2.6.3):
mswindows = (sys.platform == "win32")

which only correctly detects CPython on Windows. This line should be changed to:
mswindows = (sys.platform == "win32" or sys.platform == "cli" or sys.platform == "silverlight")

so subprocess can be utilized from IronPython as well.

This bug should be trivial to fix.

Probably it should use platform.system() == 'Windows' instead.

but, does it work even with your fix?
it seems to me that "from _subprocess import *" will fail miserably.

Also, using platform.system() == 'Windows' would exclude IronPython running on Mono.

it's not about platform detection; does IronPython have the equivalent of msvcrt.open_osfhandle()?

Is there any reason _subprocess couldn't be implemented in C#? If not, this is the first of many steps needed to get subprocess working under IronPython.

Proposed patch, with duck subprocessing. :D

Amaury is right. On Windows, _subprocess is a built-in, so the platform stuff just currently enables further failure.

Dave: My C# skills aren't the greatest, but looking at PC/_subprocess.c there are a few Win32 functions you might need to P/Invoke, but I believe a lot of the functionality is supported in .NET.

Florent's patch makes sense to me.

What does the patch achieve?

Jeff Hardy just made this change for IronPython 2.7: http://bitbucket.org/ironpython/ironlanguages/changeset/b6bb2a9a7bc5

Any opposition to us matching that so they don't need to patch Lib/subprocess.py?

sys.platform == "cli" or sys.platform == "silverlight"

It cannot happen in CPython, so I think that it's fine to leave CPython stdlib unchanged. I consider that the issue is fixed because the bug report was for IronPython and the bug was fixed there.

It doesn't matter that it can't happen in CPython. The idea is that IronPython should be able to copy as much of the stdlib as possible without having to change it.

That said, I'm not going to object if people decide this is in some sense a step too far in that direction. So I'm +0.5, Brain is +1, and Victor is -1. Any other votes? (Obviously IronPython hasn't wanted it enough to push it, so that could be considered as weighing on the negative side.)

The important line from the link in msg122717 is :-

mswindows = (sys.platform == "win32" or (sys.platform == "cli" and os.name == 'nt'))

so +1 from me unless someone can show one or more problems with it.

I'm -0, I don't really care :-) I just that the issue is old and
didn't get much attention.

Oh oh, new try in english:

I vote -0, I don't really care :-) It's just that the issue is old and didn't get much attention.

It would be good to have the library work unchanged on both implementations.

If subprocess only failed later, it would be less good, as the stdlib would then set an example that doesn't actually succeed.

Note that the attached patch (by flox) does NOT implement the discussed "or" tests on sysm.platform; it instead checks whether _subprocess it importable. Is the assumption of an accelerator module itself too implementation-specific? I'm also not sure that the test in the patch isn't too broad -- is windows the only platform with _subprocess? Because if not, then the new test would mess up logic later in the file, such as that at line 635 in Popen.__init__

(The above concerns -- other than whether it is sufficient to work -- do not apply to the change at https://bitbucket.org/ironpython/ironlanguages/commits/b6bb2a9a7bc5/ )

How about this? Should apply equally to 3.4 and default, 2.7 is different but can use the same concept (with s/_winapi/_subprocess/ among other changes).

Just to note that this is referenced from bpo-19453 pydoc and ironpython.

If os.name == 'nt' is True on IronPython then why not simply do:

    mswindows = sys.platform == "win32" or os.name == "nt"

For the record, both variants are used in different places in cPython source code. It would nice to figure out a golden standard and apply it everywhere. Maybe even add it as a new WINDOWS constant in the platform module.

The real question isn't "are we on Windows?" but rather "should we use msvcrt/_winapi or _posixsubprocess/select?", which is what my PR is designed to better fit. I could see how we wouldn't want to backport that patch to maintenance branches, though; it's a significant rearrangement. If we do want to backport a fix, I agree that simply adding or os.name == 'nt' should be sufficiently low-impact.

I don't think that we should backport this change to 3.7 and older.

I understand that the change is about supporting Cygwin. My policy to support a new platform is always the same: first fix *all* issues in master, get a working CI, find a core developer responsible to fix all issues specific to this platform, and only after that we can start discussing about backporting specific changes for that platform.

https://pythondev.readthedocs.io/cpython.html#i-want-cpython-to-support-my-platform

This one has nothing to do with Cygwin, this is about minimizing patching that IronPython (or other implementations) have to do to standard library modules.

New changeset 880d42a by Zachary Ware in branch 'master':
bpo-8110: Refactor platform detection in subprocess (GH-9053)
880d42a

Do we want to bother backporting anything, or call it fixed in 3.8 and move on?

lets call this fixed. if and only if another Python implementation pipes up as happier if this exists in an older than 3.8 version we can consider backporting the same refactoring to that code.