Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Dan Strohl <D.Strohl@F5.com>
Newsgroups: comp.lang.python
Subject: RE: What should Python apps do when asked to show help?
Date: Thu, 28 Apr 2016 17:39:57 +0000
Lines: 61
Message-ID: <mailman.205.1461865203.32212.python-list@python.org>
References: <57223b76$0$22140$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmo+p7J0wsX_RKBXH43zMDJ0n2NB0mag-LGO6BBzyqv7OQ@mail.gmail.com> <1461864606.3216317.592558881.0591528C@webmail.messagingengine.com> <b830effaaa954dad9b5c53786b4b665e@seaexchmbx03.olympus.F5Net.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Thread-Topic: What should Python apps do when asked to show help?
Thread-Index: AQHRoWw0yo/CeHHw+k+f9dhTV82UOp+gExQAgAAGoQD//4vT0A==
In-Reply-To: <1461864606.3216317.592558881.0591528C@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
Precedence: list
Xref: csiph.com comp.lang.python:107818

Yup.. another reason to use something like argparse... you define the argum=
ent descriptions, help, and when you raise an error, it automatically handl=
es the output, sending it to the right place (stderr/stdout)... as well as =
allowing you to define different levels of verbosity easily... (or not if y=
ou don't want)

Argparse isn't the best tool in the world, and there are some things that a=
nnoy me about it sometimes, but it works pretty well within its boundaries.

(and if the code's already written, I'm not suggesting that it be re-writte=
n just to move it to a common library.

> -----Original Message-----
> From: Python-list [mailto:python-list-bounces+d.strohl=3Df5.com@python.or=
g]
> On Behalf Of Random832
> Sent: Thursday, April 28, 2016 10:30 AM
> To: python-list@python.org
> Subject: Re: What should Python apps do when asked to show help?
>=20
> On Thu, Apr 28, 2016, at 13:06, Chris Angelico wrote:
> > On Fri, Apr 29, 2016 at 2:33 AM, Steven D'Aprano <steve@pearwood.info>
> > wrote:
> > > Many command line tools simply output help to stdout (or stderr, if
> > > they're evil),
> >
> > I'm not sure stderr is particularly more evil than stdout, but
> > whatever
> > :)
>=20
> When a tool has very long help and sends it to stderr:
>=20
> $ foo --help
> ok, it's scrolled off the top, and I could just scroll up, but it's so lo=
ng I'll have to
> search for what I want anyway.
> $ foo --help | less
> *help flashes on the screen, then blank ~~~~~~ screen from less*
> #@!@#$#$!#$!@#$@#!$@!#$!@#$!@#$!@#$!@#$
> $ foo --help 2>&1 | less
>=20
> Basically the only reason this ever happens is that programmers get lazy =
and
> use the same function for usage errors as for --help. A usage error messa=
ge
> *should* go to stderr (in order to show up if the program's output has be=
en
> redirected to null, and so as not to be silently piped to something that
> expects the program's normal output), but it should be short. Help should=
 go
> to stdout because the user actually requested it.
>=20
> The obvious exception, and probably the bad example that people are
> following, is programs that don't actually *have* --help, but briefly
> summarize all their options and the meanings of positional arguments in t=
he
> usage error. People start with that, and then expand it to a full-blown G=
NU-
> style --help message, but continue sending it to stderr.
> --
> https://mail.python.org/mailman/listinfo/python-list