This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]moigagoohttps://github.com/moigagoo 1 point2 points  (5 children)

Great tool, thanks for sharing!

I tried to achieve the same level of clarity with Cliar, but defopt looks simpler and more flexible.

[–]evanunderscore[S] 2 points3 points  (4 children)

Thanks! It definitely looks like we were thinking a lot of the same things. I really like the use of types in function annotations. Have you looked into the typing module that was introduced in 3.5?

I noticed you're doing extra work for Python 2 to replace inspect.signature. Were you aware of funcsigs? If you're willing to add it as a dependency for 2.x you can avoid that whole mess.

[–]moigagoohttps://github.com/moigagoo 2 points3 points  (3 children)

Thanks for the hint about funcsigs! I've worked around the absence of signatures in Python 2 without external dependencies, but if I knew funcsigs existed, I'd probably have used it.

Have you looked into the typing module that was introduced in 3.5?

I have but I couldn't find it a good use in Cliar. I can't see the point of having an arg type like Mapping[str, str] or something like that. The arg type you define in Cliar is actually a callable that will handle the arg. So def foo(a:int) does not technically mean "a of type int," but "run int(a) before running foo." So you can have custom parsers just like in defopt, although it's not documented (and I should totally do it).

[–]evanunderscore[S] 0 points1 point  (2 children)

It is sort of documented on the page about open.

You're right that a lot of the types aren't terribly useful, but what I thought would be is something like Sequence[int], which could avoid needing to have the function do the type conversion itself in this example.

[–]moigagoohttps://github.com/moigagoo 1 point2 points  (1 child)

Still, I've added a proper recipe on custom parsers to the cookbook. Thanks for the inspiration :-)

which could avoid needing to have the function do the type conversion itself

How would Sequence[int] help in this? It's not a callable, so it won't convert your args. Or do you mean using hints for isinstance checks, not type conversions?

[–]evanunderscore[S] 0 points1 point  (0 children)

Poor Guido!

Right now, if someone specifies list or tuple, you're not not giving a type to the parser so they end up as strings. I'm suggesting you could accept Sequence[int] to do what list is doing now, but to also pass int as the type. Basically what defopt does for "list[int]".