This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bethard
Recipients andybuckley, bethard, eric.araujo, gruszczy, r.david.murray, wplappert
Date 2010-04-21.19:38:15
SpamBayes Score 3.6079715e-07
Marked as misclassified No
Message-id <m2wd11dcfba1004211238u12a3a19ey6f8d059dba572488@mail.gmail.com>
In-reply-to <1271878193.2.0.986992462612.issue4256@psf.upfronthosting.co.za>
Content
2010/4/21 Filip Gruszczyński <report@bugs.python.org>:
> I don't really understand, why can't we just check if
> help-options is provided by the user and add our own,
> if it is not?

I'm sure it would be possible to do it this way. The question is
whether it makes sense to from the perspectives of code
maintainability and explaining awkward corner cases to users.

On Wed, Apr 21, 2010 at 12:29 PM, R. David Murray wrote:
> I don't see why --help-options would need to be listed in help.

Right. For argparse, suppressing the printing of --help-options in the
help message is as simple as setting help=SUPPRESS.

>  We could pick a more obscure name, too.

I think this is probably the best way forward. What is the format
that's being printed out? Is this a standard somewhere? Can we name
the flag something like "--print-parser-options-in-XXX-format"?

Steve
History
Date User Action Args
2010-04-21 19:38:16bethardsetrecipients: + bethard, eric.araujo, wplappert, andybuckley, r.david.murray, gruszczy
2010-04-21 19:38:15bethardlinkissue4256 messages
2010-04-21 19:38:15bethardcreate