parser registry about defopt HOT 4 CLOSED

defopt actually used to require you to register parsers exactly like this (there was no option to pass arguments to run), but I changed it in 1.0.0 because it felt over-engineered for my use cases and the way it works now felt simpler. However at this point you're certainly using the module more than I am, so I'm happy to defer to your judgement.

On assuming that foo(s: str) is its own parser: yes, that sounds like a sensible thing to do by default. I'd be happy to accept that change if you'd like to implement it.

On your particular use case of defining comma_separated_int_list: from a purist standpoint, I never wanted people to have to do things like that in order to manipulate the generated command line. In this particular case, with a small fix, this becomes possible:

diff --git a/defopt.py b/defopt.py
index 80c1445..ec0cbe2 100644
--- a/defopt.py
+++ b/defopt.py
@@ -335,7 +335,7 @@ def _get_type_from_hint(hint):
         list, collections_abc.Iterable, collections_abc.Sequence,  # Py>=3.7
     ]
     if ti.get_origin(hint) in container_types:
-        [type_] = ti.get_args(hint)
+        [type_] = ti.get_args(hint, evaluate=True)
         return _Type(type_, list)
     elif ti.is_union_type(hint):
         # For Union[type, NoneType], just use type.
diff --git a/examples/list_parser.py b/examples/list_parser.py
new file mode 100644
index 0000000..89063d8
--- /dev/null
+++ b/examples/list_parser.py
@@ -0,0 +1,17 @@
+from typing import List
+
+import defopt
+
+
+def example(list_of_lists_of_ints: List[List[int]]):
+    print(list_of_lists_of_ints)
+
+
+def int_list(string):
+    if not string:
+        return []
+    return [int(x) for x in string.split(',')]
+
+
+if __name__ == '__main__':
+    defopt.run(example, parsers={List[int]: int_list})

$ PYTHONPATH=. python examples/list_parser.py -l 1,2,3 4,5 6
[[1, 2, 3], [4, 5], [6]]

from defopt.

However at this point you're certainly using the module more than I am, so I'm happy to defer to your judgement.

I definitely use it a lot, and it's really useful. Thanks again for writing it :)

On assuming that foo(s: str) is its own parser.

I think that's a slightly less invasive change than explicitly having a parser registry and will probably start by implementing that.

On your particular use case of defining comma_separated_int_list [...]

I agree my approach is a bit of a hack, and didn't think of adding a parser for List[int]. It looks like even the addition of evaluate=True is unnecessary, though?

from defopt.

Thanks again for writing it :)

No problem, thank you for your many contributions!

It looks like even the addition of evaluate=True is unnecessary, though?

It was necessary for me in 3.6. The docstring for ti.get_args() mentions the default value is True on 3.7, so if you're using that, that explains why you don't need it.

from defopt.

I think this can be considered closed by #70 and #72.

from defopt.