Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #20992 > unrolled thread

Re: suppressing argparse arguments in the help

Started byPeter Otten <__peter__@web.de>
First post2012-02-28 19:07 +0100
Last post2012-02-28 19:07 +0100
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: suppressing argparse arguments in the help Peter Otten <__peter__@web.de> - 2012-02-28 19:07 +0100

#20992 — Re: suppressing argparse arguments in the help

FromPeter Otten <__peter__@web.de>
Date2012-02-28 19:07 +0100
SubjectRe: suppressing argparse arguments in the help
Message-ID<mailman.247.1330452615.3037.python-list@python.org>
Andrea Crotti wrote:

> On 02/28/2012 04:02 PM, Peter Otten wrote:
>> Andrea Crotti wrote:
>>
>>> I have a script that might be used interactively but also has some
>>> arguments that
>>> should not be used by "normal" users.
>>> So I just want to suppress them from the help.
>>> I've read somewhere that the help=SUPPRESS should do what I want:
>>>
>>>       parser.add_argument('-n', '--test_only',
>>>                           action='store_true',
>>>                           help=SUPPRESS)
>>>
>>> but that's what I get from "myapp -h", which is not exactly what I was
>>> looking for..
>>>
>>>
>>>     -f, --first_level     ==SUPPRESS== (default: False)
>>>     --never_redevelop     ==SUPPRESS== (default: False)
>>>
>>>
>>> Any other solutions?
>> That shouldn't happen. Did you reload() somewhere?
>> argparse tests object identity not equality with SUPPRESS, so you have to
>> ensure that SUPPRESS stems from the same instance of the argparse module
>> as your ArgumentParser.
>>
> 
> Ah great yes it wasn't actually the same..
> but why not just use
> if text != SUPPRESS
> instead of:
> if text is not SUPPRESS

Steven Bethard would have to answer that. 
If it were my code I would have used the equality test, but also the correct 
symbolic constant...
 
> probably the second is more safe, but they are it's still checking
> against a constant that
> is very unlikely to clash with anything..

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web