Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate platform.popen() #55586

Closed
vstinner opened this issue Mar 2, 2011 · 18 comments
Closed

Deprecate platform.popen() #55586

vstinner opened this issue Mar 2, 2011 · 18 comments
Assignees
Labels
stdlib Python modules in the Lib dir

Comments

@vstinner
Copy link
Member

vstinner commented Mar 2, 2011

BPO 11377
Nosy @malemburg, @loewis, @vstinner, @tjguk, @merwok, @briancurtin
Files
  • platform_popen.patch
  • platform_popen-2.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/merwok'
    closed_at = <Date 2011-05-24.23:22:32.816>
    created_at = <Date 2011-03-02.17:29:23.952>
    labels = ['library']
    title = 'Deprecate platform.popen()'
    updated_at = <Date 2011-05-24.23:22:32.815>
    user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2011-05-24.23:22:32.815>
    actor = 'vstinner'
    assignee = 'eric.araujo'
    closed = True
    closed_date = <Date 2011-05-24.23:22:32.816>
    closer = 'vstinner'
    components = ['Library (Lib)']
    creation = <Date 2011-03-02.17:29:23.952>
    creator = 'vstinner'
    dependencies = []
    files = ['20982', '20984']
    hgrepos = []
    issue_num = 11377
    keywords = ['patch']
    message_count = 18.0
    messages = ['129905', '129907', '129921', '129922', '129923', '129941', '129943', '129946', '129947', '129953', '129960', '129963', '135919', '135920', '135934', '135943', '136705', '136714']
    nosy_count = 8.0
    nosy_names = ['lemburg', 'loewis', 'vstinner', 'tim.golden', 'eric.araujo', 'brian.curtin', 'cvrebert', 'python-dev']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'needs patch'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue11377'
    versions = ['Python 3.3']

    @vstinner
    Copy link
    Member Author

    vstinner commented Mar 2, 2011

    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.

    @vstinner vstinner added the stdlib Python modules in the Lib dir label Mar 2, 2011
    @malemburg
    Copy link
    Member

    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.

    @vstinner
    Copy link
    Member Author

    vstinner commented Mar 2, 2011

    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.

    @malemburg
    Copy link
    Member

    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/

    @malemburg
    Copy link
    Member

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

    @vstinner
    Copy link
    Member Author

    vstinner commented Mar 3, 2011

    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: bpo-2405 (Drop w9xpopen and all dependencies).

    @malemburg
    Copy link
    Member

    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: bpo-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.

    @vstinner
    Copy link
    Member Author

    vstinner commented Mar 3, 2011

    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().

    @malemburg
    Copy link
    Member

    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.

    @vstinner
    Copy link
    Member Author

    vstinner commented Mar 3, 2011

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

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

    @malemburg
    Copy link
    Member

    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/

    @vstinner
    Copy link
    Member Author

    vstinner commented Mar 3, 2011

    Commited to 3.3 (r88721).

    @vstinner vstinner closed this as completed Mar 3, 2011
    @merwok
    Copy link
    Member

    merwok commented May 13, 2011

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

    @malemburg
    Copy link
    Member

    É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.

    @merwok
    Copy link
    Member

    merwok commented May 13, 2011

    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.

    @merwok merwok reopened this May 13, 2011
    @merwok merwok changed the title Deprecate (remove?) platform.popen() Deprecate platform.popen() May 13, 2011
    @merwok merwok self-assigned this May 13, 2011
    @malemburg
    Copy link
    Member

    É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.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented May 23, 2011

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

    @cvrebert
    Copy link
    Mannequin

    cvrebert mannequin commented May 24, 2011

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

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    stdlib Python modules in the Lib dir
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants