Thanks @vadimbo

I like this idea. I've been meaning to add more customisation via the extra **kwargs that pydantic.Field provides.

I will begin working on this as soon as I finish the big changes in #34.

Hi! Thank you for this project @SupImDos. I'd like to +1 this request for aliases so that we could have short arguments as well. Was curious if this enhancement is still planned? Thanks!

@donaldcampbelljr Certainly still on my radar, but couldn't say when I'll have time to do this.

If you (or someone else reading this) were interested in a PR, the following pointers could help:

• Update pydantic_argparse.utils.arguments.name to handle aliases provided in field.field_info.extra.
• Update tests.utils.test_arguments.test_argument_name tests for the new behaviour
• Add some new tests e.g., tests.functional.test_aliases

Some things to think about re: API / behaviour expectations

• What happens if you provide alias and aliases?
• What is the behaviour for boolean arguments
• What is the behaviour for inverted arguments (i.e., --no-<x>)

Probably some other things I am forgetting here, but it should be relatively straight forward as long as its clear what the expectations are for the edge cases.

If you wanted a hack / escape hatch for now, you could try something like the following:

# Create parser with model
parser = pydantic_argparse.ArgumentParser(model=...)

# Add `-s` short argument for existing `--string` argument
argument = parser._option_string_actions["--string"]
argument.option_strings = ("-s", "--string")
parser._option_string_actions["-s"] = argument

I haven't tested this, but to the point the pydantic_argparse.ArgumentParser is just a subclass of Python's real argparse.ArgumentParser, so if you can update arguments for that it should be applicable here.

Partially completed in #73. Going to follow it up with another PR with some tests / docs if required.

This should now be possible in v0.10.0