Get rid of argparse usage entirely.

Review Request #3074 - Created Nov. 4, 2015 and submitted

Benjy Weinberger
molsen, nhoward_tw

It had become an implementation detail, and a minor one at that.
We had already duplicated a lot of its logic (around types and actions,
in particular) in order to correctly compute defaults. So we might as
well go the extra mile and get rid of it. Especially since its init
sequence is quite expensive, and we create one argparser per scope,
which is not how it was designed to be used.

This meant we had to implement a couple of extra bits of functionality
that argparse did previously handle for us:
- choices
- nargs=?. Instead of implementing nargs fully, we now allow
an implicit_value= kwarg, which provides the value if you
specify a flag with no value (e.g., --foo instead of --foo=bar).
This is the only thing we were using nargs for, and even that
only in one place.

This allows us to simplify OptionValueContainer, as we can now guarantee
that all values set on it are of type RankedValue.

Note that this breaks one little piece of functionality that we
never wanted to begin with: argparse recognizes any unambiguous prefix
of an option. E.g., if we register --foobar, and there's no other option
that starts with --foo, then you only need to use --foo on the cmd line.
This is a very bad feature, because it means command lines will break
as soon as you add a new option with the same prefix. Sadly, there was
no way to turn it off. So it's possible that someone somewhere is
relying on this bad behavior, which is now gone. In which case they
will get an "unknown option" error, and will simply have to spell the
option correctly. They were on thin ice to begin with, so this is not
worth worrying about.

CI passes:


  • 0
  • 9
  • 2
  • 11
Description From Last Updated
Matt Olsen
Matt Olsen
Nick Howard (Twitter)
Benjy Weinberger
Benjy Weinberger
Nick Howard (Twitter)
Benjy Weinberger
Benjy Weinberger
Review request changed

Status: Closed (submitted)

Change Summary: