It seems like it is possible to create optional arguments with argparse that "override" otherwise required arguments (be it positional or required options).
A example would be the --help/-h switch, which just displays the help and exit. Now I need to implement behaviour exactly like this ; I need a switch/option that can be used without using any of the otherwise required arguments.
Take a look at how the 'help' switch is implemented:
self.add_argument(
default_prefix+'h', default_prefix*2+'help',
action='help', default=SUPPRESS,
help=_('show this help message and exit'))
You need to provide an action that short circuits argument processing; the 'help' action does this by exiting the program.
Related
I'm writing a module with custom logging utilities to be imported in other scripts.
It's based on the standard-library logging module.
One of these utilities looks like this:
import argparse as ap
def parse_log_args() -> dict:
log_arg_parser = ap.ArgumentParser(description='Parses arguments that affect logging')
log_arg_parser.add_argument(
'--level',
dest='level',
help='Sets logging level',
choices=['DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL']
)
log_args, _ = log_arg_parser.parse_known_args()
return vars(log_args)
This function looks for arguments that have to do with logging (even though only --level is defined for the time being) and parses those independently of (and before) all others so that the logging can be configured early on and used in the rest of the script.
The goal here is to remain flexible and be able to quickly plug-in support for these arguments, both in scripts that expect no other arguments and in those that do.
From the point of view of simply parsing arguments this works: this function runs first, parses --level and then the script-specific parser comes and handles the rest.
The problem, however, is the help text. When I run a script that calls this function with --help it only displays the help text from this first parser and not from the script-specific one. So something like this:
Parses arguments that affect logging
optional arguments:
-h, --help show this help message and exit
--level {DEBUG,INFO,WARNING,ERROR,CRITICAL}
Sets logging level
Is there a way to combine the help-texts from all the ArgumentParser instances in a script?
Alternatively: Is there a different way to achieve this in a flexible/plug-in kind of way, that is, without modifying existing ArgumentParsers or having to add them to scripts that don't yet use them?
PS: A similar question has been asked before here: Argparse combine --help directives but the proposed ideas don't really solve the problem:
Define the first parser with add_help=False: This would hide the option from the user which I would prefer not to do.
Use subcommands somehow: doesn't seem to be applicable here.
I think this might fit the bill:
import argparse
part1 = argparse.ArgumentParser(add_help=False)
#... some parsing takes place ...
part2 = argparse.ArgumentParser(add_help=True, parents=[part1])
part1 parser must be fully initialized for parents to work.
More on the topic:
https://docs.python.org/3/library/argparse.html#parents
I've been searching the documentation for a long time and still can't figure this out.
In the SCons documentation, there is discussion about adding a PreAction or PostAction. In the examples, they call an example method:
foo = Program('foo.c')
AddPreAction(foo, 'pre_action')
This calls 'pre_action' before 'foo.c' is compiled and linked. However, there is no explanation about what format 'pre_action' must take.
I have discovered that there are several pre-built actions, such as 'Copy'. However, I cannot find the source of 'Copy' to reverse-engineer it and write my own.
Can anyone point me to a guide as to how to create my own Actions? I either need an interface for calling my own method such as 'pre_action' above, or a guide for writing an Action class.
Really, even just some example code that is actually complete enough to use would be helpful...
The manpage section Action Objects lists the types of things that can be passed to the Action factory function to create an action; that is also what you pass to AddPostAction and AddPreAction as the second argument - that is, either an Action already made by a previous call to Action, or something that can be converted into one like a command string, or a list of such, or a function with appropriate signature. Pre/Post will simply call the Action function with that argument. So in that section, where there's an example with a call to Action, you could just plug that argument into AddPreAction, or you could save the result of calling Action and give that as the argument to AddPreAction.
The amount of flexibility here makes it a little tricky to document concisely.
(btw the source to Copy is a function called copy_func but you probably don't want to use that form because it's a couple of extra levels of abstraction you won't need)
According to a std_files.e that I have found, read_character requires not end_of_file, but it doesn't specify any post-condition; and last_character has no preconditions. Therefore, what happens if you call last_character before calling read_character?
last_character will give a default value '%U' unless there is some unusual code around, e.g. the code that redefines this feature or accesses an object input on STD_FILES and reads something without using STD_FILES, etc.
In this question
argparse: require either of two arguments
I find a reference to the solution I want, but it isn't right.
I need at least 1 of 2 options to be present, option1, option2 or both...
The add_argument_group function doesn't have a required argument.
The add_mutually_exclusive function has it, but it forces me to choose between the 2 options, which is not what I want.
rds,
argument_group just controls the help display. It does not affect the parsing or check for errors. mutually_exclusive_group affects usage display and tests for occurrence, but as you note, its logic is not what you want.
There is a Python bug issue requesting some form of nested 'inclusive' group. But a general form that allows nesting and all versions of and/or/xor logic is not a trivial addition.
I think your simplest solution is to test the args after parsing. If there is a wrong mix of defaults, then raise an error.
Assuming the default for both arguments is None:
if args.option1 is None and args.option2 is None:
parser.error('at least one of option1 and option2 is required')
What would be meaningful usage line? required mutually exclusive' uses(opt1 | opt2).(opt1 & opt2)might indicate that both are required. Your case is anon-exclusive or`
usage: PROG [-h] (--opt1 OPT1 ? --opt2 OPT2)
Is it possible to turn off abbreviation in getopt_long()? From the man page:
Long option names may be abbreviated if the abbreviation is unique or is an exact match for >some defined option.
I want to do this because the specification I have received for a piece of code requires full-length exact match of the flags, and there are many flags.
Codeape,
It appears there isn't a way to disable the abbreviation feature. You aren't alone in wishing for this feature. See: http://sourceware.org/bugzilla/show_bug.cgi?id=6863
Unfortunately, It seems the glibc developers don't want the option as the bug report linked above was resolved with "WONTFIX". You may be out of luck here :-\
If you use argp_parse() instead of getopt() (highly reccommended, BTW), you can access the exact flag entered by the user through
state->argv[ state->next - 2 ]
It's a bit of a hack, but should work.
This is not perfect solution but you can check exact arg given by a user after calling getopt_long() (normally within switch) like below:
if (strcmp(argv[optind-1], "--longoption") == 0)
optind points a next argument that you need to process. Thus, you can access the original arg using optind-1.