Message234576
| Author |
gregory.p.smith |
| Recipients |
Marat.Mavlyutov, berker.peksag, gajdig, gregory.p.smith, steve.dower, tim.golden, vstinner, zach.ware |
| Date |
2015年01月23日.20:29:27 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1422044967.37.0.551596923685.issue23223@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I can apply this to subprocess32 but it is going to look much more like:
+#ifndef MS_WINDOWS /* WTF is anyone compiling on Windows? Shouldn't work! */
+# define HAVE_UNISTD_H 1
+#endif
+#ifdef HAVE_UNISTD_H
#include <unistd.h>
+#endif
The real question is why do you need it?
_posixsubprocess.c makes no sense to compile on Windows as far as I understand it. subprocess32 in its entirety makes no sense to use on Windows as nobody is testing, maintaining or updating the Windows side of its code.
The module backport was created for reliable use on POSIX platforms where the existing python 2.x subprocess module falls short.
I recommend:
try:
import subprocess32 as subprocess
except ImportError:
import subprocess
OR
if sys.platform.startswith('win'):
import subprocess
else:
import subprocess32 as subprocess
in cross platform code that needs to run on Windows.
....
BTW, anyone know what update do I need to make to setup.py and its PIP categorization to mark it as unavailable on Windows? |
|