Thanks for the deets. I have to say, though, that after a bit of early thrashing with argparse, as a Python n00b, I have come to think ... it's fine. Like you, I have a "frags" file with boilerplate for argparse, and that, plus the experience gained from that early thrashing, pretty much means that using argparse is a solved problem, from my perspective.
I will admit that, up until recently, I still had some vague feelings of dissatisfaction, but the more I thought about it, the more I realized, well, what more do you want? Yes, the few lines of code involved with setting up argparse are not the most beautiful thing ever seen in a text editor, but (1) they work, and (2) as you suggest, there's no reason why this chunk of code couldn't live in a separate function. On that second point, though, I don't see much advantage. What is gained, a cleaner __main__ or main()?
Ultimately, it came down to my realizing that writing scripts/programs that support cmdline args is just not that big a deal. The universe of possibilities is just not that vast. The most complicated situation I have yet come up with involves one switch, one option, and an arbitrary number of positional arguments (e.g., filenames, so the script will work with something like `py myscript.py *.txt`.
I looked at click a couple of times, a while ago, when argparse was frustrating me, and I don't remember why, but I do remember being thoroughly unmotivated to learn it, based on a reading of docs. I'm not harshing on it -- if it works for other people, that's all good. I'm just saying that handling cmdline args is a fairly limited problem, and that for me, argparse does the job.
You can test it by passing args yourself instead of sys.argv, import it to reuse it, swap it dynamically with other arguments, and it keeps the separation of concern.
Hey this pretty cool. We use both argparse and click at my place of work. I looked around very quickly and couldn't find a nice way to introduce type hints to argparse. Do you have any experience with that?
argparse does allow you to specify the required data type for a given argument, at least to a limited extent, using the keyword arg `type`. If this is not sufficient from your perspective, could you give me an example of where it is not?
I understood that to be his desire. I just didn't see how it would work in practice. What would be gained by telling mypy (or similar) that a given command line are is supposed to be a str or an int?
Two things that I can think of: (1) the possibility that mypy could detect a call to the function that's passing the wrong type of arg, (2) the way various documentation utils (e.g., mkdocstrings) and IDEs can use the info.
Thanks for the deets. I have to say, though, that after a bit of early thrashing with argparse, as a Python n00b, I have come to think ... it's fine. Like you, I have a "frags" file with boilerplate for argparse, and that, plus the experience gained from that early thrashing, pretty much means that using argparse is a solved problem, from my perspective.
I will admit that, up until recently, I still had some vague feelings of dissatisfaction, but the more I thought about it, the more I realized, well, what more do you want? Yes, the few lines of code involved with setting up argparse are not the most beautiful thing ever seen in a text editor, but (1) they work, and (2) as you suggest, there's no reason why this chunk of code couldn't live in a separate function. On that second point, though, I don't see much advantage. What is gained, a cleaner __main__ or main()?
Ultimately, it came down to my realizing that writing scripts/programs that support cmdline args is just not that big a deal. The universe of possibilities is just not that vast. The most complicated situation I have yet come up with involves one switch, one option, and an arbitrary number of positional arguments (e.g., filenames, so the script will work with something like `py myscript.py *.txt`.
I looked at click a couple of times, a while ago, when argparse was frustrating me, and I don't remember why, but I do remember being thoroughly unmotivated to learn it, based on a reading of docs. I'm not harshing on it -- if it works for other people, that's all good. I'm just saying that handling cmdline args is a fairly limited problem, and that for me, argparse does the job.
> What is gained
You can test it by passing args yourself instead of sys.argv, import it to reuse it, swap it dynamically with other arguments, and it keeps the separation of concern.
But for a simple script, it's overkill.
Hey this pretty cool. We use both argparse and click at my place of work. I looked around very quickly and couldn't find a nice way to introduce type hints to argparse. Do you have any experience with that?
argparse does allow you to specify the required data type for a given argument, at least to a limited extent, using the keyword arg `type`. If this is not sufficient from your perspective, could you give me an example of where it is not?
He meant hints for static type check, not runtime checks
I understood that to be his desire. I just didn't see how it would work in practice. What would be gained by telling mypy (or similar) that a given command line are is supposed to be a str or an int?
Not trying to argue. Just trying to understand.
How would it be different from any function call type hints benefits ?
Two things that I can think of: (1) the possibility that mypy could detect a call to the function that's passing the wrong type of arg, (2) the way various documentation utils (e.g., mkdocstrings) and IDEs can use the info.
Good. That lives return types, ide help and completion. Can be something some people want or not depending of the effort.
The only way is to cast(), and it's one if the reason I use typer more and more. It wraps click with types and dep injection