argspec.kwonlyargs

[froh]

Hi, I have a function which takes a number of kwonlyargs and then arbitrary values (think file or directory names), like so:

import plac

def foo(*moo, gu=4, gac=None):
    print(f"{gu=}\n{gac=}\n{moo=}\n")

if __name__ == '__main__':


    plac.call(foo)

    P = plac.parser_from(foo)
    
    print(P.argspec)
    P.print_help()

this gives this output and seems to ignore the keyword-only arguments guand gac:

$ python .\plac_kwonlyargs.py --gu=77 foo bar
gu=4
gac=None
moo=('foo', 'bar', '--gu=77')

FullArgSpec(args=[], varargs='moo', varkw=None, defaults=None, kwonlyargs=['gu', 'gac'], kwonlydefaults={'gu': 4, 'gac': None}, annotations={})
usage: plac_kwonlyargs.py [-h] [moo ...]

positional arguments:
  moo

options:
  -h, --help  show this help message and exit

I'd expect the program to print

$ python .\plac_kwonlyargs.py --gu=77 foo bar
gu=77
gac=None
moo=('foo', 'bar')

FullArgSpec(args=[], varargs='moo', varkw=None, defaults=None, kwonlyargs=['gu', 'gac'], kwonlydefaults={'gu': 4, 'gac': None}, annotations={})
usage: plac_kwonlyargs.py [-h] [--gu=int] [--gac=Any] [moo ...]

positional arguments:
  moo
  gu    [4]
  gac   []

options:
  -h, --help  show this help message and exit

is this a pebcac on my side or intentional or a bug?

[froh]

okay, I figured when I use decorators and give up on keyword only parameters gu and gac, I get it running from the command line:

import plac

@plac.opt('gu', type=int, abbrev='G')
@plac.opt('gac', type=str)
def foo( gu: int = 4, gac: str| None = None, *moo):
    print(f"{gu=}\n{gac=}\n{moo=}\n")

if __name__ == '__main__':
    plac.call(foo)

    P = plac.parser_from(foo)
    print(P.argspec)
    P.print_help()

however that's highly counterintuitive! the command line named arguments (CLI options) are now positional in python, and not kw only arguments any more.

$ python .\plac_kwonlyargs.py
gu=4
gac=None
moo=()

FullArgSpec(args=['gu', 'gac'], varargs='moo', varkw=None, defaults=(4, None), kwonlyargs=[], kwonlydefaults=None, annotations={'gu': (None, 'option', 'G', <class 'int'>, None, None), 'gac': (None, 'option', 'g', <class 'str'>, None, None)})
usage: plac_kwonlyargs.py [-h] [-G 4] [-g None] [moo ...]

positional arguments:
  moo

options:
  -h, --help           show this help message and exit
  -G 4, --gu 4         [4]
  -g None, --gac None  [None]

if I'd call foo(4, 5, 6, 7, 8, 9) in python then the first two would override guand gac.

I haven't seen this discussed in the repo (searched for kwonlyargs)

[ialbert]

I would say (as a maintainer rather than original creator of the software) is that the keyword arguments are somewhat of an additional, cool feature but may not play well with all other features,

[froh]

hmmm... I think the convention of all function parameters after *args being kwonly goes waaaay back.

If I'd at some point create a PR to support that, would the project be open to that?

I really think plac should support it.

the one thing that confuses me is the somewhat unorthodox use of annotations, which these days seem overlap with typing annotations.

I also looked into google fire, which alas doesn't use the function annotated types for sys.args parsing, but deduces the type from the given string o-O, on the plus side, fire supports dropping from the CLI into the REPL.

not sure which route to go at this point.

[micheles]

The design of plac is like 20 years old and predates both kwonly arguments and function annotations.

[froh]

The design of plac is like 20 years old and predates both kwonly arguments and function annotations.

typing came later but kwonly was there, albeit not called like that:

Named arguments after *args go back to very early 2.x and the semantics were there, too: The named arguments following a *args are kwonly implicitly. you couldn't provide a value to them except as kw parameter. we just didn't call them kwonly...

anyhow. my Q is rather: is plac "frozen", maintenance only? or would it be worthwhile sharing kwonly args support as a PR?

[micheles]

is plac "frozen", maintenance only? or would it be worthwhile sharing kwonly args support as a PR?

That depends on the will of the current maintainer ;-)

[ialbert]

It is not frozen, and I would be happy to merge a pull request.

But backward compatibility is considered important so the new features should not break the tests beyond what is absolutely necessary

(edited)