I understand if they're deprecating it because they plan to replace it with something else, but if they don't then I'll be pretty disappointed. From their docs, it looks like some of their other subcommands have shorthands which conflict with `-h'? Fine, I guess, but that just means when `-h' does work it'll shoot people in the foot with that other behavior.
Software that clearly knows what I want, but refuses to, annoys me so much. For example,
$ python3
Python 3.9.0 (default, Dec 2 2020, 10:34:08)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
because they added `quit' as a top level variable with a `__str__' defined which returns that string. Do anything else! Make the `__str__' definition quit the program or something, test if it's being run at the top level in the CLI and quit, special case the CLI input so if only `quit' is entered, it quits. Heck, maybe just prefill the `quit()' on the next line so I just have to hit return. Do anything but instruct me to do what you should have done in the first place.If I make a mistake - tell me. If you allow me to do it slightly wrong then suddenly in my universe there is no consistency between commands and that is way worse than being told what I did wrong.
Though I get your general point.
$ python3
Python 3.8.6 (default, Nov 18 2020, 23:56:33)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>> q = quit
>>> quit = "foo"
>>> quit
'foo'
>>> quit()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'str' object is not callable
>>> q()
$ >>> print(inspect.getsource(quit.__call__))
def __call__(self, code=None):
try:
sys.stdin.close()
except:
pass
raise SystemExit(code)Still weird though, since -h is indeed a very very common shorthand used in many commands.