Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #20992 > unrolled thread
| Started by | Peter Otten <__peter__@web.de> |
|---|---|
| First post | 2012-02-28 19:07 +0100 |
| Last post | 2012-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.
Re: suppressing argparse arguments in the help Peter Otten <__peter__@web.de> - 2012-02-28 19:07 +0100
| From | Peter Otten <__peter__@web.de> |
|---|---|
| Date | 2012-02-28 19:07 +0100 |
| Subject | Re: 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..
Back to top | Article view | comp.lang.python
csiph-web