You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I realize this may be re-opening a can of worms, but I was looking for a way to re-support --key v1 v2 v3 for Container traits in argparse-based CLI handling, originally added in #322 by @ankostis. That support was one of the main reasons I felt comfortable refactoring a codebase to use traitlets. While trying to upgrade to traitlets==5.1, I found out that traitlets was now silently discarding v2 v3 due to #582 (comment) (none of my applications use positional arguments).
I was able to patch this for my applications in a rather convoluted way by having them inherit a mixin to change the argparse loader, using #360:
classFixNArgsMixin(HasTraits):
def_create_loader(self, ..):
class_DefaultOptionDict(loader._DefaultOptionDict):
def_add_kv_action(self, key):
self[key] =loader._KVAction(
# ..nargs="+", # not ideal, but not sure what else can be done, unless we restrict ourselves to Application.classes, resolve these traits and look up trait.multiplicity
)
classKVArgParser(argparse.ArgumentParser):
# same as loader.KVArgParser, but with _DefaultOptionDictclassKVArgParseConfigLoader(loader.KVArgParseConfigLoader):
parser_class=KVArgParserreturnKVArgParserConfigLoader(..)
classMyApp(FixNArgsMixin, Application):
foo=List(config=True).tag(multiplicity="+")
MyApp().initialize(["--MyApp.foo", "a", "b"])
This is pretty verbose and frail since it re-implements a significant amount of the traitlets.config.loader internals. One idea I was considering is to support an allow_nargs=True argument to _KVArgParser() which will set nargs="+" in _DefaultOptionDict, and that way the above method could be shortened to return KVArgParserConfigLoader(.., allow_nargs=True).
Significantly easier to type/autocomplete out --App.my_long_trait_name 1 2 3 4 vs --App.my_long_trait_name 1 --App.my_long_trait_name 2 --App.my_long_trait_name 3 --App.my_long_trait_name 4
Note: I understand that the multiplicity feature was buyer-beware since it was not officially released (and that traitlets is to an extent "semi-private"), and also the significant complexity in trying to handle nargs together with positional arguments, hence why I don't wish to request any changes in the current default behavior.
cc @minrk@Carreau, apologies in advance for wall of text
The text was updated successfully, but these errors were encountered:
Hi, I realize this may be re-opening a can of worms, but I was looking for a way to re-support
--key v1 v2 v3
forContainer
traits inargparse
-based CLI handling, originally added in #322 by @ankostis. That support was one of the main reasons I felt comfortable refactoring a codebase to usetraitlets
. While trying to upgrade totraitlets==5.1
, I found out thattraitlets
was now silently discardingv2 v3
due to #582 (comment) (none of my applications use positional arguments).I was able to patch this for my applications in a rather convoluted way by having them inherit a mixin to change the argparse loader, using #360:
This is pretty verbose and frail since it re-implements a significant amount of the
traitlets.config.loader
internals. One idea I was considering is to support anallow_nargs=True
argument to_KVArgParser()
which will setnargs="+"
in_DefaultOptionDict
, and that way the above method could be shortened toreturn KVArgParserConfigLoader(.., allow_nargs=True)
.Why I use
nargs="+"
:nargs="+"
, and matches theargparse
behavior of consumingnargs="+"
instead of positional arguments--App.my_long_trait_name 1 2 3 4
vs--App.my_long_trait_name 1 --App.my_long_trait_name 2 --App.my_long_trait_name 3 --App.my_long_trait_name 4
Note: I understand that the
multiplicity
feature was buyer-beware since it was not officially released (and thattraitlets
is to an extent "semi-private"), and also the significant complexity in trying to handlenargs
together with positional arguments, hence why I don't wish to request any changes in the current default behavior.cc @minrk @Carreau, apologies in advance for wall of text
The text was updated successfully, but these errors were encountered: