gh-92248: Deprecate type, choices, metavar parameters of argparse.BooleanOptionalAction by sobolevn · Pull Request #103678 · python/cpython (original) (raw)

@rhettinger thank you for your input. However, I don't quite agree with some of your points.

Changing the behavior will be inconvenient for people who happened to have fed in an unused argument in code that is currently functioning correctly

Two things here:

  1. Changing the behavior will be inconvenient: Yes, it can cause a new warning. But, this is pretty easy to deal with: just remove the argument. It won't require any compat code or migration plan. I think that this is a good thing, because it helps to indicate a problem with your code. And, of course, people with the correct code won't have any warnings at all
  2. currently functioning correctly: I don't think that we can call this code "correct". Here's the first example:

from argparse import * parser = ArgumentParser() parser.add_argument('--foo', action=BooleanOptionalAction, type=int) # we expect int parser.parse_args(['--foo']) # but get bool Namespace(foo=True)

Here's the code does not "function correctly" in a sense that type is ignored. While user explicitly asks to use int.

The second example:

from argparse import * parser = ArgumentParser() parser.add_argument('--foo', action=BooleanOptionalAction, choices=['on', 'off']) parser.parse_args(['--foo']) Namespace(foo=True)

And again: user specifies two values that must be respected. But, they are ignored.

We also do not document this behaviour:
Снимок экрана 2023-04-29 в 12 59 28

So, any user might expect it to work similarly to other action types. Which is not the case right now.

All in all, I see this as an improvement:

  1. We show what's wrong and do not break any code
  2. In the future we will have the correct signature that does the correct thing