Extract of the documentation:
----
15.14.3.1. Win95/98 specific

platform.popen(cmd, mode='r', bufsize=None)

Portable popen() interface. Find a working popen implementation preferring win32pipe.popen(). On Windows NT, win32pipe.popen() should work; on Windows 9x it hangs due to bugs in the MS C library.
----

Python 3 doesn't support Windows 9x/Me anymore: we should deprecate it, or maybe directly remove it.

subprocess.Popen() is a better alternative: it supports Unicode, it handles EINTR, etc.

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner@haypocalc.com>:
> 
> Extract of the documentation:
> ----
> 15.14.3.1. Win95/98 specific
> 
> platform.popen(cmd, mode='r', bufsize=None)
> 
> Portable popen() interface. Find a working popen implementation preferring win32pipe.popen(). On Windows NT, win32pipe.popen() should work; on Windows 9x it hangs due to bugs in the MS C library.
> ----
> 
> Python 3 doesn't support Windows 9x/Me anymore: we should deprecate it, or maybe directly remove it.
> 
> subprocess.Popen() is a better alternative: it supports Unicode, it handles EINTR, etc.

Does it prevent a shell window from opening on Windows ?

Does subprocess.Popen() use the system's PATH for finding the
executable ?

Since it's a documented API, we could replace it with an implementation
that uses subprocess.Popen(), but not remove it.

os.popen() is deprecated since Python 2.6 ("Use the subprocess module.") and it is no more documented in Python 3. The following documentation explains how to replace os.popen() by subprocess:

http://docs.python.org/py3k/library/subprocess.html#replacing-os-popen-os-popen2-os-popen3

> Does it prevent a shell window from opening on Windows ?

Yes, but only if shell=True.

> Does subprocess.Popen() use the system's PATH for finding the
executable ?

Yes. The subprocess module calls os.get_exec_path() which reads PATH environment variable.

> Since it's a documented API, we could replace it with an
> implementation that uses subprocess.Popen(),

platform_popen.patch patchs platform.popen() to reuse os.popen() (which uses subprocess). It adds also tests (there was no test for platform.popen)

> but not remove it.

Can't we at deprecate platform.popen in favor of subprocess, with a documentation to explain how to port code to subprocess?

My patch doesn't touch platform documentation.

--

os.popen() does still exist in Python 3.2, but it is no more documented. Its documentation should be fixed or the function should be removed.

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> os.popen() is deprecated since Python 2.6 ("Use the subprocess module.") and it is no more documented in Python 3. The following documentation explains how to replace os.popen() by subprocess:
> 
> http://docs.python.org/py3k/library/subprocess.html#replacing-os-popen-os-popen2-os-popen3
> 
>> Does it prevent a shell window from opening on Windows ?
> 
> Yes, but only if shell=True.
> 
>> Does subprocess.Popen() use the system's PATH for finding the
> executable ?
> 
> Yes. The subprocess module calls os.get_exec_path() which reads PATH environment variable.

One more question:

Doe subprocess work from inside Windows GUI applications ?

(I added the _popen class to work around issues with those
 a long while back)

>> Since it's a documented API, we could replace it with an
>> implementation that uses subprocess.Popen(),
> 
> platform_popen.patch patchs platform.popen() to reuse os.popen() (which uses subprocess). It adds also tests (there was no test for platform.popen)

Hmm, but if os.popen() is no longer supported in Python 3, how can
we still use it in platform ?

The os module still provides an popen() function which uses subprocess.

The documentation for the os module says:

http://docs.python.org/py3k/library/os.html?highlight=os#os.plock

"""
os.popen(...)

    Run child processes, returning opened pipes for communications. These functions are described in
section File Object Creation.
"""

If you then go to the suggested section, there's no mention of os.popen().
popen() is also referenced in a few other places in the os module
documentation.

The documentation should either be removed completely, or restored to
match the existing os module function popen().

>> but not remove it.
> 
> Can't we at deprecate platform.popen in favor of subprocess, with a documentation to explain how to port code to subprocess?

Sure, just not remove it immediately.

> My patch doesn't touch platform documentation.

> --
> 
> os.popen() does still exist in Python 3.2, but it is no more documented. Its documentation should be fixed or the function should be removed.

Indeed. See above.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

BTW: The _popen class can be removed as well, if the function
is replaced with os.popen() or the subprocess module Popen().

> Does subprocess work from inside Windows GUI applications?

You mean: Python embedded in another program? I don't know. How can I test that?

I never see any warning in subprocess documentation saying that subprocess doesn't work on Windows in some cases. subprocess uses CreateProcessW() (by _subprocess.CreateProcess).

I suppose that CreateProcessW() can always be used.

Note: subprocess does still support Windows 9x. But there is an issue to drop this support: #2405 (Drop w9xpopen and all dependencies).

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
>> Does subprocess work from inside Windows GUI applications?
> 
> You mean: Python embedded in another program? I don't know. How can I test that?

Try to use platform from within IDLE or PythonWin. The popen()
implementation in platform was added mostly to address issues
on Windows.

> I never see any warning in subprocess documentation saying that subprocess doesn't work on Windows in some cases. subprocess uses CreateProcessW() (by _subprocess.CreateProcess).
> 
> I suppose that CreateProcessW() can always be used.

Probably yes, but it's better to check.

> Note: subprocess does still support Windows 9x. But there is an issue to drop this support: #2405 (Drop w9xpopen and all dependencies).

The platform module in Python3 no longer needs to support platforms
that are not supported by Python2.

Some background on the compatibility requirements of platform:

The main reason for making platform portable across various Python
versions was to be able to use one version for all commonly used
Python versions. It originated from code I wrote for our build
machines and was intended to be used in multi-Python version build
processes.

For the Python3 branch, the same stability should be applied, but
keeping Python 3.2 compatibility is enough, IMO, since previous
3.x versions did not get much use.

> Try to use platform from within IDLE ...

I tried subprocess.call('calc.exec'): it works.

I tried p=subprocess.Popen('echo hello', shell=True, stdout=subprocess.PIPE); p.communicate(): it works too (I get the output and there is no MS-DOS popup).

> Hmm, but if os.popen() is no longer supported in Python 3, how can
> we still use it in platform ?

platform.popen() and os.popen() have the same requirement: call process.wait() on file.close(). os.popen() does already implement that using _wrap_close. I don't want to copy/paste the code from os. os.popen() does still exist, why not reusing it?

Anyway, if we remove os.popen(), we should remove platform.popen() too. But I don't want/plan to remove os.popen().

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
>> Try to use platform from within IDLE ...
> 
> I tried subprocess.call('calc.exec'): it works.
> 
> I tried p=subprocess.Popen('echo hello', shell=True, stdout=subprocess.PIPE); p.communicate(): it works too (I get the output and there is no MS-DOS popup).

Great. Thanks for checking.

>> Hmm, but if os.popen() is no longer supported in Python 3, how can
>> we still use it in platform ?
> 
> platform.popen() and os.popen() have the same requirement: call process.wait() on file.close(). os.popen() does already implement that using _wrap_close. I don't want to copy/paste the code from os. os.popen() does still exist, why not reusing it?
> 
> Anyway, if we remove os.popen(), we should remove platform.popen() too. But I don't want/plan to remove os.popen().

Ok.

If you remove the _popen class as well, the patch can go in.

New patch deprecating platform.popen() and removing _popen.

Marc-Andre: Do you agree to deprecate platform.popen() in favour of subprocess?

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> New patch deprecating platform.popen() and removing _popen.

Patch looks good.

> Marc-Andre: Do you agree to deprecate platform.popen() in favour of subprocess?

Yes. We can start the deprecation process in 3.3.

Thank you,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

Commited to 3.3 (r88721).

Is it on purpose that there is a doc deprecation but no [Pending]DeprecationWarning?

Éric Araujo wrote:
> 
> Éric Araujo <merwok@netwok.org> added the comment:
> 
> Is it on purpose that there is a doc deprecation but no [Pending]DeprecationWarning?

No, I guess just an oversight.

haypo asked me on IRC if I’d like to make a patch for this; I will, in some weeks.

With respect to the recent thread about deprecations and 2.7 → 3.<latest> migrations, should this be a DeprecationWarning or PendingDeprecationWarning?  Neither is displayed by default, but using PDW would put the actual removal a version later.  I’m not sure about the timeframe here.

Éric Araujo wrote:
> 
> Éric Araujo <merwok@netwok.org> added the comment:
> 
> haypo asked me on IRC if I’d like to make a patch for this; I will, in some weeks.
> 
> With respect to the recent thread about deprecations and 2.7 → 3.<latest> migrations, should this be a DeprecationWarning or PendingDeprecationWarning?  Neither is displayed by default, but using PDW would put the actual removal a version later.  I’m not sure about the timeframe here.

Please follow the PEP 387 guidelines. We are starting the deprecation
process with 3.3. I don't think we need a PendingDeprecationWarning
in 3.3, but we might want to add one to 2.7.

New changeset e44b851d0a2b by Victor Stinner in branch 'default':
Issue #11377: platform.popen() emits a DeprecationWarning
http://hg.python.org/cpython/rev/e44b851d0a2b

Slight tangent: Regarding os.popen()'s [documentation] status, there's a bug for that: http://bugs.python.org/issue9382