Why spawnvp not implemented on Windows?
Hi all, I've been looking at python 2.5 today and what I notices is absense of spawnvp with this comment in os.py: # At the moment, Windows doesn't implement spawnvp[e], # so it won't have spawnlp[e] either. I'm wondering, why so? Searching MSDN I can see that these functions are implemented in CRT: spawnvp: http://msdn2.microsoft.com/en-us/library/275khfab.aspx spawnvpe: http://msdn2.microsoft.com/en-us/library/h565xwht.aspx I can also see that spawnvp and spawnvpe are currently wrapped in posixmodule.c, but for some reason on OS/2 only. Forgive me if I'm wrong but shouldn't it work when #if defined(PYOS_OS2) is changed to #if defined(PYOS_OS2) || defined(MS_WINDOWS) around spawnvp and spawnvpe wrappers and in posix_methods? At least when I did it with my copy, nt.spawnvp seems to work fine...
On 10/12/06, Alexey Borzenkov <snaury@gmail.com> wrote:
At least when I did it with my copy, nt.spawnvp seems to work fine...
Hi everyone again. I've created patch for spawn*p*, as well as for exec*p* against trunk, so that when possible it uses crt's execvp[e] (defined via HAVE_EXECVP, if there are other platforms that have it they will need to define HAVE_EXECVP and HAVE_SPAWNVP). Fix is in os.py and posixmodule.c: http://snaury.googlepages.com/python-win32-spawn_p_.patch Should I submit it to sourceforge as a patch, or someone can review it as is?
On Thu, Oct 12, 2006, Alexey Borzenkov wrote:
Should I submit it to sourceforge as a patch, or someone can review it as is?
Always submit patches; that guarantees your work won't get lost. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra
Alexey Borzenkov schrieb:
Should I submit it to sourceforge as a patch, or someone can review it as is?
Please consider also exposing _wspawnvp, depending on whether path argument is a Unicode object or not. See PEP 277 for guidance. Since this would go into 2.6, support for Windows 95 isn't mandatory. Regards, Martin
On 10/13/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Please consider also exposing _wspawnvp, depending on whether path argument is a Unicode object or not. See PEP 277 for guidance. Since this would go into 2.6, support for Windows 95 isn't mandatory.
Umm... do you mean that spawn*p* on python 2.5 is an absolute no?
On Oct 12, 2006, at 11:53 PM, Alexey Borzenkov wrote:
On 10/13/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Please consider also exposing _wspawnvp, depending on whether path argument is a Unicode object or not. See PEP 277 for guidance. Since this would go into 2.6, support for Windows 95 isn't mandatory.
Umm... do you mean that spawn*p* on python 2.5 is an absolute no?
Unless you have a time machine and manage to get it in before 2.5.0 is released :-). Micro releases (2.5.1, 2.5.2, ...) only contain bugfixes, not new features. Ronald
Alexey Borzenkov schrieb:
On 10/13/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Please consider also exposing _wspawnvp, depending on whether path argument is a Unicode object or not. See PEP 277 for guidance. Since this would go into 2.6, support for Windows 95 isn't mandatory.
Umm... do you mean that spawn*p* on python 2.5 is an absolute no?
Yes. No new features can be added to Python 2.5.x; Python 2.5 has already been released. Regards, Martin
Forgot to include python-dev... On 10/13/06, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Umm... do you mean that spawn*p* on python 2.5 is an absolute no? Yes. No new features can be added to Python 2.5.x; Python 2.5 has already been released.
Ugh... that's just not fair. Because of this there will be no spawn*p* in python for another two years. x_x I have a workaround for this, that tweaks os module: [...snip wrong code...] It should have been: if (not (hasattr(os, 'spawnvpe') or hasattr(os, 'spawnvp')) and hasattr(os, 'spawnve') and hasattr(os, 'spawnv')): def _os__spawnvpe(mode, file, args, env=None): import sys from errno import ENOENT, ENOTDIR from os import path, spawnve, spawnv, environ, defpath, pathsep, error if env is not None: func = spawnve argrest = (args, env) else: func = spawnv argrest = (args,) env = environ head, tail = path.split(file) if head: return func(mode, file, *argrest) if 'PATH' in env: envpath = env['PATH'] else: envpath = defpath PATH = envpath.split(pathsep) if os.name == 'nt' or os.name == 'os2': PATH.insert(0, '') saved_exc = None saved_tb = None for dir in PATH: fullname = path.join(dir, file) try: return func(mode, fullname, *argrest) except error, e: tb = sys.exc_info()[2] if (e.errno != ENOENT and e.errno != ENOTDIR and saved_exc is None): saved_exc = e saved_tb = tb if saved_exc: raise error, saved_exc, saved_tb raise error, e, tb def _os_spawnvp(mode, file, args): return os._spawnvpe(mode, file, args) def _os_spawnvpe(mode, file, args, env): return os._spawnvpe(mode, file, args, env) def _os_spawnlp(mode, file, *args): return os._spawnvpe(mode, file, args) def _os_spawnlpe(mode, file, *args): return os._spawnvpe(mode, file, args[:-1], args[-1]) os._spawnvpe = _os__spawnvpe os.spawnvp = _os_spawnvp os.spawnvpe = _os_spawnvpe os.spawnlp = _os_spawnlp os.spawnlpe = _os_spawnlpe os.__all__.extend(["spawnvp", "spawnvpe", "spawnlp", "spawnlpe"]) But the fact that I have to use similar code anywhere I need to use spawnlp is not fair. Notice that _spawnvpe is simply a clone of _execvpe from os.py, maybe if the problem is new API in c source, this approach could be used in os.py? P.S. Although it's a bit stretching, one might also say that implementing spawn*p* on windows is not actually a new feature, and rather is a bugfix for misfeature. Why every other platform can benefit from spawn*p* and only Windows can't? This just makes os.spawn*p* useless: it becomes unreliable and can't be used in portable code at all.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 12, 2006, at 8:46 PM, Alexey Borzenkov wrote:
Ugh... that's just not fair. Because of this there will be no spawn*p* in python for another two years. x_x
Correct, but don't let that stop you. That's what distutils and the Cheeseshop are for. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRS7l+XEjvBPtnXfVAQJy6gP/RkGcTXDCBYM/WL/X+sNiTp6ydvFPg20u SrxUb/vQpNVkjA2GkFJJAXArnsxn8LB2MC+rPDRkkNMYcFw5JAUcf0IR1L+AdFnC h+68f03XDzbeB8uqVrQ6xObEPXmanvhx1uCrApqFq+zOzqMNlbzUlyGCTLu0Cw9v CYLa+aaKFAA= =dX0B -----END PGP SIGNATURE-----
[Alexey Borzenkov]
Umm... do you mean that spawn*p* on python 2.5 is an absolute no?
[Martin v. Löwis]
Yes. No new features can be added to Python 2.5.x; Python 2.5 has already been released.
[Alexey Borzenkov]
Ugh... that's just not fair. Because of this there will be no spawn*p* in python for another two years. x_x
Or the last 15 years. Yet somehow people still have kids ;-)
... But the fact that I have to use similar code anywhere I need to use spawnlp is not fair.
"Fair" is a very strange word here. Pain in the ass, sure, but not fair? Doesn't make sense.
... P.S. Although it's a bit stretching, one might also say that implementing spawn*p* on windows is not actually a new feature, and rather is a bugfix for misfeature.
No. Introducing any new function is obviously a new feature, which would become acutely and catastrophically visible as soon as someone released code using the new function in 2.5.1, and someone tried to /use/ that new code under 2.5.0. Micro releases of Python do not introduce new features -- take that as given. It's been tried before, for what appeared to be "very good reasons" at the time, and we lived to regret it deeply. It won't happen again.
Why every other platform can benefit from spawn*p* and only Windows can't?
Just the obvious reason: because so far nobody cared enough to do the work of writing code, docs and tests for some of these functions on Windows.
This just makes os.spawn*p* useless: it becomes unreliable and can't be used in portable code at all.
It's certainly true that it can't be used in portable code, at least not before Python 2.6.
On Friday 13 October 2006 10:46, Alexey Borzenkov wrote:
But the fact that I have to use similar code anywhere I need to use spawnlp is not fair. Notice that _spawnvpe is simply a clone of _execvpe from os.py, maybe if the problem is new API in c source, this approach could be used in os.py?
Oddly, "fair" isn't a constraint in PEP-0006. Backwards and forwards compatibility between all point releases in a major release is. Adding it to os.py rather than C code doesn't make a difference.
P.S. Although it's a bit stretching, one might also say that implementing spawn*p* on windows is not actually a new feature, and rather is a bugfix for misfeature. Why every other platform can benefit from spawn*p* and only Windows can't? This just makes os.spawn*p* useless: it becomes unreliable and can't be used in portable code at all.
"One" might say that. I wouldn't. It stays out until 2.6. Sorry Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Alexey Borzenkov wrote:
P.S. Although it's a bit stretching, one might also say that implementing spawn*p* on windows is not actually a new feature, and rather is a bugfix for misfeature. Why every other platform can benefit from spawn*p* and only Windows can't? This just makes os.spawn*p* useless: it becomes unreliable and can't be used in portable code at all.
any reason you cannot just use the "subprocess" module instead, like everyone else? </F>
On 10/13/06, Fredrik Lundh <fredrik@pythonware.com> wrote:
any reason you cannot just use the "subprocess" module instead, like everyone else?
Oh! Wow! I just simply didn't know of its existance (I'm pretty much new to python), and both distutils and SCons (I was looking inside them because they are major build systems and surely had to execute compilers somehow), and upon seeing that each of them invented their own method of searching path created a delusion as if inventing custom workarounds was the only way... Sorry... x_x
Alexey Borzenkov wrote:
any reason you cannot just use the "subprocess" module instead, like everyone else?
Oh! Wow! I just simply didn't know of its existance (I'm pretty much new to python), and both distutils and SCons (I was looking inside them because they are major build systems and surely had to execute compilers somehow), and upon seeing that each of them invented their own method of searching path created a delusion as if inventing custom workarounds was the only way... Sorry... x_x
no problem. someone should really update the documentation to make sure that os.spawn and os.open and commands and popen2 and all the other 80%-solutions at least point to the subprocess module... (and if the library reference had been stored in a wiki, I'd fixed that before any- one else even got this mail...) </F>
Alexey Borzenkov wrote:
Oh! Wow! I just simply didn't know of its existance (I'm pretty much new to python), and both distutils and SCons (I was looking inside them because they are major build systems and surely had to execute compilers somehow), and upon seeing that each of them invented their own method of searching path created a delusion as if inventing custom workarounds was the only way... Sorry... x_x
SCons is still compatible with Python 1.5. Distutils was written in the 1.5-1.6 timeframe; it has been updated since, but it is basically unmaintained at this point (if you exclude the setuptools stuff which is its disputed maintenance/evolution). subprocess has been introduced in Python 2.4. -- Giovanni Bajo
participants (9)
-
"Martin v. Löwis" -
Aahz -
Alexey Borzenkov -
Anthony Baxter -
Barry Warsaw -
Fredrik Lundh -
Giovanni Bajo -
Ronald Oussoren -
Tim Peters