Skip to content

argparse version action should print to stdout, not stderr #63120

Closed

Description

@wm75
mannequin
BPO 18920
Nosy @jwilk, @ezio-melotti, @serhiy-storchaka, @wm75
Files
  • issue18920.1.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 = None
    closed_at = <Date 2013-09-06.13:57:07.095>
    created_at = <Date 2013-09-04.12:30:47.440>
    labels = ['easy', 'type-bug']
    title = 'argparse version action should print to stdout, not stderr'
    updated_at = <Date 2018-03-24.16:17:16.912>
    user = 'https://github.com/wm75'

    bugs.python.org fields:

    activity = <Date 2018-03-24.16:17:16.912>
    actor = 'serhiy.storchaka'
    assignee = 'none'
    closed = True
    closed_date = <Date 2013-09-06.13:57:07.095>
    closer = 'eli.bendersky'
    components = []
    creation = <Date 2013-09-04.12:30:47.440>
    creator = 'wolma'
    dependencies = []
    files = ['31587']
    hgrepos = []
    issue_num = 18920
    keywords = ['patch', 'easy']
    message_count = 13.0
    messages = ['196905', '196908', '196910', '196911', '196912', '196916', '196918', '196919', '197068', '197069', '197072', '314373', '314374']
    nosy_count = 8.0
    nosy_names = ['bethard', 'jwilk', 'ezio.melotti', 'eli.bendersky', 'python-dev', 'serhiy.storchaka', 'wolma', 'Stefan Sauer']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue18920'
    versions = []

    Activity

    1. wm75 commented on Sep 4, 2013

      wm75mannequin
      MannequinAuthor

      Hi,
      I just noticed that version output generated via the
      **'version' action** of the **argparse** module
      is routed to stderr. I'd expect regular output to go to stdout instead.
      The current behavior also seems inconsistent to me because --help
      prints to stdout.
      Best,
      Wolfgang

    2. added
      type-bugAn unexpected behavior, bug, or error
      on Sep 4, 2013
    3. elibendersky commented on Sep 4, 2013

      elibenderskymannequin
      Mannequin

      Yes, it seems like an oversight to me. Printing --version to stdout is more customary (Python itself does it, and most other tools do too).

      A question comes up about backwards compatibility. I would definitely not change it in 2.x - it's just not worth it. As for 3.x, should this go into 3.3 too or just 3.4?

    4. ezio-melotti commented on Sep 4, 2013

      @ezio-melotti
      Member

      Only on 3.4.
      Python prints the version on stdout since 3.4 -- before it used stderr:
      3.3$ ./python -V 2> /dev/null
      3.3$ ./python -V > /dev/null
      Python 3.3.2+

      3.4$ ./python -V 2> /dev/null
      Python 3.4.0a1+
      3.4$ ./python -V > /dev/null

      This might also explain why argparse uses stderr (other modules/scripts in the stdlib might do the same too).

    5. elibendersky commented on Sep 4, 2013

      elibenderskymannequin
      Mannequin

      On Wed, Sep 4, 2013 at 6:26 AM, Ezio Melotti <report@bugs.python.org> wrote:

      Ezio Melotti added the comment:

      Only on 3.4.
      Python prints the version on stdout since 3.4 -- before it used stderr:
      3.3$ ./python -V 2> /dev/null
      3.3$ ./python -V > /dev/null
      Python 3.3.2+

      3.4$ ./python -V 2> /dev/null
      Python 3.4.0a1+
      3.4$ ./python -V > /dev/null

      This might also explain why argparse uses stderr (other modules/scripts in
      the stdlib might do the same too).

      Ah, right. On 3.4 Python's main.c uses printf for --version; on earlier
      versions it's fprintf(stderr...)

      I guess it's a no-brainer then; 3.4 has to be changed, but not earlier
      versions. I'll whip up a quick patch.

    6. elibendersky commented on Sep 4, 2013

      elibenderskymannequin
      Mannequin

      The Python executable change is from bpo-18338

    7. elibendersky commented on Sep 4, 2013

      elibenderskymannequin
      Mannequin

      Patch attached

    8. serhiy-storchaka commented on Sep 4, 2013

      @serhiy-storchaka
      Member

      This might also explain why argparse uses stderr (other modules/scripts in the stdlib might do the same too).

      Lib/trace.py, Tools/pynche/Main.py, and Tools/i18n/pygettext.py write to the stdout.

      Lib/smtpd.py and Tools/i18n/msgfmt.py write to the stderr.

      The optparse module also writes to the stdout.

    9. serhiy-storchaka commented on Sep 4, 2013

      @serhiy-storchaka
      Member

      You misplace Misc/NEWS entry in wrong section -- "What's New in Python 3.4.0 Alpha 1".

      I think this change (as change of bpo-18338) worths the mentioning in Doc/whatsnew/3.4.rst.

      Did you run all test suite? This change can affect other tests.

    10. python-dev commented on Sep 6, 2013

      python-devmannequin
      Mannequin

      New changeset ec9a4b77f37b by Eli Bendersky in branch 'default':
      Issue bpo-18920: argparse's default version action (for -v, --version) should
      http://hg.python.org/cpython/rev/ec9a4b77f37b

    11. elibendersky commented on Sep 6, 2013

      elibenderskymannequin
      Mannequin

      Thanks, I moved the NEWS entry to the right place. Yes, all tests pass. I'll update whatsnew separately.

    12. python-dev commented on Sep 6, 2013

      python-devmannequin
      Mannequin

      New changeset 587bdb940524 by Eli Bendersky in branch 'default':
      Update whatsnew/3.4 wrt. --version going to stdout. bpo-18338, bpo-18920, bpo-18922
      http://hg.python.org/cpython/rev/587bdb940524

    13. changed the title [-]argparse module version action[/-] [+]argparse version action should print to stdout, not stderr[/+] on Jul 4, 2016
    14. StefanSauer commented on Mar 24, 2018

      StefanSauermannequin
      Mannequin

      Is there a workaround for python2? The issue is that autotools is checking that installed tools support --help and --version and it expects those to stdout:

      bad=0; pid=$$; list="gtkdoc-check gtkdoc-depscan gtkdoc-fixxref gtkdoc-mkdb gtkdoc-mkhtml gtkdoc-mkhtml2 gtkdoc-mkman gtkdoc-mkpdf gtkdoc-rebase gtkdoc-scan gtkdoc-scangobj gtkdocize"; for p in $list; do \
        case '  ' in \
         *" $p "* | *" ../../$p "*) continue;; \
        esac; \
        f=`echo "$p" | sed 's,^.*/,,;s,x,x,'`; \
        for opt in --help --version; do \
          if "/home/ensonic/projects/gnome/gtk-doc/gtk-doc-1.27.1/_inst/bin/$f" $opt >c${pid}_.out \
               2>c${pid}_.err </dev/null \
               && test -n "`cat c${pid}_.out`" \
               && test -z "`cat c${pid}_.err`"; then :; \
          else echo "$f does not support $opt" 1>&2; bad=1; fi; \
        done; \
      done; rm -f c${pid}_.???; exit $bad
      gtkdoc-check does not support --version
      gtkdoc-fixxref does not support --version
      gtkdoc-mkdb does not support --version
      gtkdoc-mkhtml does not support --version
      gtkdoc-mkhtml2 does not support --version
      gtkdoc-mkman does not support --version
      gtkdoc-mkpdf does not support --version
      gtkdoc-rebase does not support --version
      gtkdoc-scan does not support --version
      gtkdoc-scangobj does not support --version
      Makefile:637: recipe for target 'installcheck-binSCRIPTS' failed
    15. serhiy-storchaka commented on Mar 24, 2018

      @serhiy-storchaka
      Member

      You can implement your own version action which outputs to stdout and use it for -V and --version.

    16. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      easytype-bugAn unexpected behavior, bug, or error

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions