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...
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On 10/12/06, Alexey Borzenkov <snaurygmail.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_.pat
ch

Should I submit it to sourceforge as a patch, or someone can
review it as is?
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

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 (aahzpythoncraft.com)           <*>         http://www.pythoncraft.co
m/

"If you don't know what your program is supposed to do,
you'd better not
start writing it."  --Dijkstra
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

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
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On 10/13/06, "Martin v. Löwis" <martinv.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?
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On Oct 12, 2006, at 11:53 PM, Alexey Borzenkov wrote:

> On 10/13/06, "Martin v. Löwis" <martinv.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

_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

Alexey Borzenkov schrieb:
> On 10/13/06, "Martin v. Löwis"
<martinv.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
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

Forgot to include python-dev...

On 10/13/06, "Martin v. Löwis" <martinv.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.
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

-----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+sNiTp6ydvFP
g20u
SrxUb/vQpNVkjA2GkFJJAXArnsxn8LB2MC+rPDRkkNMYcFw5JAUcf0IR1L+A
dFnC
h+68f03XDzbeB8uqVrQ6xObEPXmanvhx1uCrApqFq+zOzqMNlbzUlyGCTLu0
Cw9v
CYLa+aaKFAA=
=dX0B
-----END PGP SIGNATURE-----
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

[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.
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com