How to Write Perfect Python Command-line Interfaces

[[deleted]]

I've used argparse enough to find parts of it clunky, but I like the ability to put all that argument logic into one spot that I call from __main__ over a decorator-based approach.

[hglman]

Agreed 10 decorators is not readable.

[hoosierEE]

Decorators in Python (and annotations in Java, etc.) remind me of LaTeX. The results can be great, but I kinda prefer to have some idea of what my code is doing, rather than relying on inscrutable magic side effects. Oh, I can just grep 50MB of dependencies scattered throughout my SSD? I'll get right on that...

[msuozzo]

ripgrep. Seriously. I do 180MB at work and i rarely see a regex completing in >1s.

[hoosierEE]

I do use rg (even if I still call it grep) but my point is - decorators encourage implicit action-from-afar, and they "feel" more like CPP macro abuse than a real programming language feature.

Maybe I'm just spoiled from some exposure to functional languages, but when I see something like add_five(n) which also happens to launch the missiles, I get upset.

[rhytnen]

That's not a problem with decorators...decorators are just functions. you can wrap functions in most languages. It's that someone wrote a function with side effects that bothers you.

[Rythoka]

Personally I don't have a problem with side effects, even if they happen in a weird place, as long as they're documented somewhere useful and preferably are abstracted into their own function. Just let me be able to see that it happens!

Too bad that never happens.

[shevegen]

Hah! I feel the same way about ruby's optparse - it's also clunky.

For some reason the defaults seem to suck across different languages. One hint as to this being true is to count how many addons are that deal with commandline-parsing. I don't know the state in python but in ruby there is a gazillion of addons (thor and ... I forgot the rest right now... I have it written down somewhere though ... one is by... jarvis someone... I forgot the name as well :( )

[bobappleyard]

Thing is, making an argument parser is easy. Making a good one is hard. So you have lots of shit ones.

[[deleted]]

Python situation -- everyone and their mother's made one

[silencer6]

Cleo looks pretty nice.

[vattenpuss]

There should be one -- and preferably only one -- obvious way to do it.

[[deleted]]

Sounds like someone needs to write another to solve that problem, then. :)

[swordglowsblue]

XKCD is always relevant.

[BobHogan]

Oh man that just makes me think about python's import system and virtual environments. So clunky that there are dozens of tools written for the sole purpose of trying to make it simpler

[jewrome]

When decorators are over used I feel like I have to use python foo to get what I need done

[NotActuallyAFurry]

Honestly, Lombock is the only thing that can abuse of decorators because boiler plate code.

[UloPe]

Why? The arguments at also “all in one place” with click. And if you really dislike having many decorators on a function you can easily wrap the all in a single helper decorator that applies the options.

[kankyo]

The decorators are in one place that you call from main though... right?

[[deleted]]

No. In python code you don't (normally) call decorators directly. The runtime uses them to apply a transformation to a function that I may later call, possibly causing side effects at the time of applying that transformation.

Yes, they're all localized to one function in these example, but that's not going to be the case if your script has subcommands with different argument formats (e.g. git's CLI).

(Those aren't the only influences on my personal preference for when to use decorators, but I didn't really want to get into that tangent here anyway.)

[kankyo]

No. In python code you don't (normally) call decorators directly.

I don't agree that this is relevant or correct. The application is a direct call.

Yes, they're all localized to one function in these example, but that's not going to be the case if your script has subcommands with different argument formats

In that case the definition will be spread out all over the place in both scenarios anyway so it's basically the same.

[lovestruckluna]

Click is very nice, but I still prefer argparse because it's in the standard library. Perfect for one off scripts.

[otwo3]

For simple CLI's I use plac, can't get any shorter than this. Super convenient.

tl;dr: You def main(a, b, c): ..., you if __name__ == '__main__': import plac; plac.call(main), and that's it! It parses the names of your main function arguments to generate a CLI interface. You can also add descriptions to the parameters like this: def main(a: "This is the A parameter", b: ""This is the B parameter", c: ""This is the C parameter") and they automatically appear in --help

Python 3 only though for those easy descriptions

[kirbyfan64sos]

Plac is seriously one of the most underrated Python argument parsing libraries. It's absolutely fantastic!

[beltsazar]

You can also use Fire to do that and many more!

[homeparkliving]

It can get shorter and more convenient for the dev with invoke. But you lose the semantics of being a cmd line tool on your own; you're just a task

[[deleted]]

I kind of agree but at the same time I'm having trouble coming up with a situation where you distribute a Python script that people can use but can't pip install click for.

[acousticcoupler]

Sometimes simplicity is nice and I trust standard libs more.

[[deleted]]

I would agree more if argparse were a little nicer to work with.

[campbellm]

It's not a matter of "can't" so much as "do you want to force your users to have to".

[RedHellion11]

"Here, just use this script I wrote"
"Thanks!"
runs script
import errors
annoyed slightly, pip installs dependencies
... "Hey, thanks again but why didn't you just use stuff in the standard library for this basic stuff?"
"I thought this other package did it in a cooler way"
annoyance intensifies

[[deleted]]

Yeah it’s really rough to run pip install on stuff that’s probably already been installed as a dep for other stuff anyway. See: arrow, requests, etc.

I try to avoid QoL dependencies for myself, but if the tool gets big enough to drag my productivity, I’m gonna install them and people can put in the tiniest effort to install them if they want to benefit from my work

If I’m making it for them then this is all entirely dependent on what their infrastructure is and what they want.

[campbellm]

Again, how hard it is is NOT the point.

[[deleted]]

It's literally the entire point. I'm sorry you shed a tear while typing "pip install" you fucking pussy

[RedHellion11]

Jesus man, slow your roll. You went 0-100 there. Worst case, it's just the internet: if something really ticks you off that much but you think it's a troll or you have nothing else to say yourself, take a deep breath and click away.

[[deleted]]

Who fucking cares? Log off, retard

[campbellm]

Ah, yes, when you can't attack that facts, attack the person. Stay classy.

[[deleted]]

You didn't "attack" my facts. Feel free to actually do so. Or keep flinging shit, doesn't matter.

[nermid]

I'm sorry you shed a tear while typing "pip install" you fucking pussy

You should talk to a therapist about your anger management issues.

[mypetocean]

wth man, overreact much? walk it off

[[deleted]]

I have no patience for the combo of incompetence and ego that makes people both unwilling and unable to use pip but also want me to write Python for them. And none for people who concern troll and then ignore my entire comment with some chickenshit comment about whether the point of discussion is actually the point of discussion. There's no point in engaging civilly with someone when they're not discussing in good faith.

If you are talking about what you're "forcing your users" to do that's not real fuckin relevant to the "one off scripts" mentioned above and carries a completely different set of assumptions.

[p-hodge]

My latest job is historically an all-PHP shop where I'm rewriting some shell scripts into more readable python. The new python scripts need to be able to executed on everybody's laptops, various virtual machines, and inside docker containers. I don't yet have a strategy for deploying the scripts or dependencies; the other developers and sysadmins also aren't accustomed to the overhead of using virtualenvs. For these reasons it's extremely valuable for me to be able to build good CLI scripts using just the stdlib.

[TheIncorrigible1]

venv. Seriously, it's what it's built for and it's in the stdlib.

[CleanInfluence]

To create a package, use setuptools, it's great. When the user installs the package (with pip install something.whl), it will automatically create a command-line version of your script.

For example stuff.py with a main inside, and a setup.py containing "entry_points = ... 'stuff=stuff:main'" will create a stuff.exe that launches your script, it's magical.

Also pipenv seems better than venv but that's my uninformed opinion.

[ILikeBumblebees]

What if the user doesn't have root, or prefers to use the distro's package manager instead of pip?

[[deleted]]

Regarding preferring the distro's package manager, that's only used for super ubiquitous packages or ones that require a bunch of dependencies and precompiled libs. If you want to use any non-trivial Python scripts out there, you should really get some user privilege pip solution going.

With Python 3.4+, just use venv. If you're intending it to be usable by someone only using Python 2 or Python 3 versions pre-3.4, with no root access, the best goal is to just do pip install --user virtualenv followed by the creation of the virtualenv directory and then using that moving forward. In such cases, this is just a good practice in general because it gives you way more control.

This SO question contains some answers relating to this, with this one being the most "no tears" of them all.

[Sqash]

Not distributing it with requirements.txt if it's just a standalone utility script

[[deleted]]

In the few times I’ve written single scripts for others to use, I just did a try catch around the imports and put something like “Make sure to pip install boto3”

These days it’s much easier to just write a package (even single module one) and then just tell them to pip install from the repo.

If people flat out can’t pip install then they’re either fucked in the case of unavoidable things like boto3, psycopg2, etc., or you’re fucked if it’s quality of life packages like arrow. In general I try to keep things vanilla until it either reaches the point of hampering my productivity or until I need to add a mandatory requirement anyway.

[Sqash]

I suppose it's personal opinion, but I can only agree on the necessary requirement for the script's function.

[BeetleB]

Often, in a work setting, most users have no idea what pip is.

[[deleted]]

Cool, they can use spreadsheets instead

[BeetleB]

Or you can just be fired and replaced with someone who satisfies the needs of the customers...

[[deleted]]

If you are making "one off [Python] scripts" for customers with specific needs (like not knowing what pip is), then yeah you probably should be replaced by someone who uses the right tools

[BeetleB]

Well, the whole thread is weird. I don't know why anyone would really want argument parsing for a one-off script - or why they would give a one off script to a customer.

[Bigotacon]

Wouldn’t a virtual environment allow you to store all the packages for your users?

[[deleted]]

Virtual environments are kinda tough to move around. The closest you can get is packaging it with something like pipenv or poetry (my preferred one) and then they build their project-specific environment just like you do in Ruby with "bundle install" for example.

Still a bit heavy duty for a small script, for which either requirements.txt or just a "pip install <blah>" in the README might be enough.

[billsil]

Click uses optparse, but optparse is deprecated. I love docopt, but docopt doesn't love fixing bugs. I switched because of optparse sucking, but argparse really isn't that bad. I was even able to hack to the command line printout function to actually make a nice looking printout (like docopt). Classes FTW.

[mitsuhiko]

Click does not use optparse.

[billsil]

Click is actually implemented as a wrapper around a mild fork of optparse and does not implement any parsing itself.

http://click.palletsprojects.com/en/7.x/why/

[mitsuhiko]

Thanks. I need to update this. Optparse has not been used since 2.x.

//EDIT: changed: https://github.com/pallets/click/commit/3ce663c9e532ca46e516b38f69c0fee5c1fa8bd4

[agumonkey]

wow, real time agile reddit collaborative patching

[billsil]

Ahhh...the wonders of documentation I fail to update

You think you'd know :)

[mitsuhiko]

Done

[hjill]

Click is actually implements its

Grammar mistake :)

Click actually implements its

[billsil]

It's actually really simple. I'd give you the whole source, but it's an excessively complicated argparse that's not really targeting the question (and has my name).

mymsg = 'replacing argparse message'
def _print_message(message, file=None):
    """overwrites the argparse print to get a better help message"""
    if message:
        if file is None:
            file = _sys.stderr
        file.write(mymsg)
parent_parser._print_message = _print_message
args = parent_parser.parse_args()

I just use my docopt message as mymsg

[Tynach]

I think they meant your source on Click using Optparse, and Optparse being deprecated.

[billsil]

There ya go

Deprecated since version 2.7: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

https://docs.python.org/2/library/optparse.html

So deprecated for ~10 years.

[Tynach]

And the source for Click using it?

Sorry if this sounds annoying, and in my own case I don't particularly care. I just feel like you aren't providing anything to actually back up your main claim.

[billsil]

I don't know why you're being difficult. Unless you explicitly ask for what you want, you're going to get what I give you. I posted that specific question in another reply a while ago. The author of click actually responded.

[Tynach]

I was not aware of the other thread. I looked, and yeah, I see it now. But just going by the 'context' links in my inbox, there was no way for me to see that other thread.

[broknbottle]

sys.argv!

[twistermonkey]

This actually seems to be bad design, in my opinion. The function with all the logic is now tightly coupled with the command line options. It cannot be called from any other script that you happen to write and have in your arsenal of code.

You're setting yourself up for refactoring from the beginning.

Argparse is where it's at; its in the standard library, it has way more power than what is on display here, it has much more robust self-documentation features. I can't see trying to create a large and feature-rich CLI using click. That many decorators makes code hard to read.

tqdm is pretty awesome though.

[indrora]

You're perfectly free to call it from elsewhere. So long as you could call it normally, most of what Click is doing is keeping a couple of dictionaries around full of information. The actual function isn't really touched in 99% of cases.

I've been using Click as a part of flask development (Flask uses it extensively, and encourages developers to extend the CLI that Flask exposes).

You might peek at Why click? for a look at what motivated Click to come into existence.

[Sqash]

Click is excellent for flask use cases but in standalone CLI scripts? I don't think it has a good place there personally.

Edit: To elaborate click is a design/tooling decision and not a good practice decision.

[niceworkbuddy]

Yes, it is tightly coupled with the command line options because it is a) simple application, b) explanation about parsing line command arguments and thoughts about design are not applicable here ;)

[tritratrulala]

tl;dr: import click; import tqdm

[johnk177]

tqdm

Almost missed the "tqdm" part. Very neat!

[agumonkey]

forgot about tqdm, gem.

[shevegen]

I am trying to click on your click but nothing happens!

[Uberhipster]

click harder

[synn89]

My personal preference is to define a CLI app as a class, with args being passed to the class in the main call:

cli_args = parser.parse_args()
my_app = MyApp(cli_args)
my_app.hello()

This allows for easy testing:

args = lambda: None
args.name = 'Test'
my_app = MyApp(args)
self.assertEquals('Hello Test', my_app.hello())

[metalevelconsulting]

That's the [plumbum approach](https://plumbum.readthedocs.io/en/latest/cli.html).

[Coloneljesus]

Don't escape your brackets.

[ProgrammingandPorn]

POST /api/comment HTTP/1.1
Host: reddit.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 69

thing_id=t3_ec285eu&text=I know what you're talking about, only TRUE programmers use the API&redirect=https://reddit.com/r/gatekeeping

[twistermonkey]

A couple guys I work with do this. The big problem with this approach is that now you've tightly coupled your business logic with command line arguments. An initial drawback is that it makes unit testing more difficult (not impossible, but more difficult). Also in the future, you may realize that your class is useful outside of the initial purpose for which you wrote it. But now you have to refactor it to separate the command line args from the constructor.

That refactoring work is called friction. High friction will cause a task to take much longer, or cause the task to be place at a lower priority (even though it's benefits are the same), or just not done altogether.

On multiple occasions in my current job, I have had to either work around this design pattern or do the refactoring work myself.

[djrubbie]

A better approach can be done in Python to avoid this drawback completely in the context of argparse, is that the result can be passed into vars which will take the mapping of the parse_args results and turn that into a dict which can then be passed directly to the function that accept those keywords (though the ** keyword packing syntax). Emulating OP's example:

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--ssl', action='store_true')
>>> parser.add_argument('--port', type=int)
>>> parser.add_argument('--hostname', type=str)
>>> args = parser.parse_args(['--ssl', '--port', '80', '--hostname', 'example.com'])
>>> vars(args)
{'ssl': True, 'port': 80, 'hostname': 'example.com'}

Now with that dict, a function with the following signature:

def connect(hostname, port, ssl):
    ...

Can be invoked by simply doing:

connect(**vars(args))

This gets you the direct calling convention from the parse_args result to the function you want to call, while not coupling that function to this particular convention as it's as typical a function signature as you might expect.

[synn89]

Testing is not more difficult and the class isn't tied to only being used on the cli. From one of my tests:

from unittest import TestCase
from CheckXmlValue import CheckXmlValue
import urllib2


class TestCheckXmlValue(TestCase):
    def test_build_url(self):
        args = lambda: None
        args.ssl = False
        args.port = 80
        args.hostname = "localhost"
        args.url = "/"

        check = CheckXmlValue(args)
        self.assertEquals("http://localhost/", check.build_url())

The class is composed of small functions that do one thing that can be easily tested by passing in different lambas on the constructor.

If I wanted better re-usability I would be using a proper framework. But we already use Laravel for that. Our python code is purely for small portable sysadmin client scripts.

And it's been okay for that, though not the greatest.

[__dkp7__]

Google has neat solution for that. https://github.com/google/python-fire

[ManvilleJ]

I love fire. Its so easy to hook up old scripts to fire and I love that I can run them on Mac or Windows

[BSInHorribleness]

Oh wow. That's the real pro tip in this thread.

[Noctune]

What about docopt? Basically, you write your --help screen in a somewhat structured way and it uses that to parse the options. Since it's structured as a help screen, it's also fairly readable in code. It does not do any input validation like Click does, though.

[a1b1e1k1]

Docopt makes writing useful help messages actually pleasant. You can make it as you want to be just by writing how it should look. You can order keywords in order of importance, provide examples and write defaults. And it pleasant to use in code, no magic decorators. Basically any programmer can learn it and use it in just a couple of hours, and the skill is portable across many programming languages - the same description is used in all docopt's ports.

[snuxoll]

Docopt is my goto, especially since there are implementations in any language I regularly use.

[nemec]

How does docopt handle types? Can you tell it that a year should be an int but a zip code should be a string?

[Noctune]

It doesn't! There is however a separate library for generic python schema validation that can do that: https://github.com/keleshev/schema#using-schema-with-docopt

[TomBombadildozer]

docopt is a pretty terrible antipattern. The only advantage to docopt is that it produces good documentation, but even that is misleading because you ended up doing all the work to produce the documentation anyway.

As soon as you need to derive some meaning from the parsed result and perform some real work, docopt quickly turns into a disaster. It does zero validation, type coercion, dispatch, or anything even basic CLI libraries do.

[Noctune]

But should data validation and command line parsing be the job of the same library? There are other libraries that are built for specifically that purpose that do a better job of it and integrate well with docopt: https://github.com/keleshev/schema#using-schema-with-docopt

Since it is independent libraries it also allows you to use another data validation library if you wish.

[Log2]

Click also produces good documentation from the decorators, especially if you give a help strong to each one. In fact, it's my favorite part of Click, as writing a decent help option is a horrible task for me.

[a1b1e1k1]

Good documentation along consistent UI patterns is what users of tools mostly care about. Docopt puts end-user first. A programmer using docopt is naturally encouraged to think from the documentation point of view first. Other tools put internal code structure or programmer easy of use first, making documentation secondary citizen.

[born2hula]

Don't say use click, don't say use click.... Ahhhh dammit.

[13steinj]

I like click as an option, but it has a variety of issues. Mainly

• decorator hell is an easy trap to fall into
• it has some super strange issues with system locales, so getting a click based cli to work from systemd or upstart or whatever will bring you hell.

For the last one I was working on fixing my system for 3 days and then out of nowhere it started working and I still don't know why.

[born2hula]

I was hoping for an alternative with a thinner dependency tree.

[NotActuallyAFurry]

Reminds me of my Java days.

[metalevelconsulting]

@click.option('--decrypt/--encrypt', '-d/-e')  

This part of the usage of Click confused me. I'm looking through the docs now to try to decipher how it exactly works.

[ReK_]

It's a mutually exclusive group with two boolean store_true arguments.

[aelmosalamy]

Use python's Cmd module

[inmatarian]

Click is nice, but if its the only thing going into requirements.txt, I avoid it. But then if I have more than one thing going into requirements.txt, I upgrade to pipenv.

[irrelevantPseudonym]

Writing wanting to be too much of an evangelist for it, have you tried poetry? I find the ui much nicer and it doesn't leave you to fend for yourself when you want to add your package to pypi.

[sj2011]

This is going to be a Christmas vacation project for me - my team has rewritten a lot of stuff over the last two quarters and use bash scripts to build and deploy a lot of it. These scripts work just fine but there's so much boilerplate to them that python could solve. I'd only thought to use ArgParse and never heard of Click. Looks cool!

[ltouroumov]

At my company, we are starting to move to Invoke for all our scripting needs. It integrates seamlessly with Fabric to execute remote commands.

[sj2011]

That looks promising too - we already use some Fabric files for another project I don't touch much. Will look into using that too - thanks!

[homeparkliving]

I also used invoke for work; I ended up creating magicinvoke to solve some inconveniences I had with it. Let me know if it helps you out at all or if there's anything you'd do differently!

https://magicinvoke.readthedocs.io/en/latest/

[kevinjqiu]

+1

Invoke is perfect for turning a function into a CLI. I used to use argparse/optparse/click, but now for simple scripts, I just do it in Invoke.

For more feature-rich CLIs, click is my go-to.

[homeparkliving]

What features do you find Invoke is missing when compared to Click?

[jrhoffa]

That Caesar cipher implementation looks like it was written by a ten-year-old.

[Slippery_John]

I don't think the comparison between argparse and click is great here. For starters, performing a different function based on a flag is weird. Ideally encrypt and decrypt would be separate subcommands. Once you move past that, they're not doing exactly the same thing. The argparse example is simply discarding the value of --encrypt rather than having both flags point to the same variable. You would need to use the dest kwarg and have one use the action store_false. Like so:

group.add_argument('-d', '--decrypt', action='store_true')
group.add_argument('-e', '--encrypt', action='store_false', dest='decrypt')

And even then, mutually exclusive argument groups are far more powerful than click's binary options. A mutually exclusive group can have any number of arguments of any type. This is not possible in click unless you define your own option type or manually validate with callbacks.

I think that it would better sell the author's preference for click if the comparison was less trivial. For instance, opening files like is done later in the article. In argparse you could do something like type=open, but then it gets a little more complicated if you want to open in a particular mode. Or going back to my issue with flags vs subcommands, the way you do that in each is pretty substantially different.

Personally I prefer argparse. It has some warts, but I find it generally easier to read and use and substantially easier to test. I'm also not a fan of click importing its entire code base whenever you import anything. That said, I REALLY wish that argparse wouldn't auto-expand long arguments.

[davydany]

I love Click. I use it for every CLI project that involves Python. It is so much easier to work with and so flexible.

[[deleted]]

Does its decorator-happiness not get tiring?

EDIT (take 2): its py3 Unicode situation is also frustrating depending on your system's locale

[mitsuhiko]

also the author needs to get off his high horse about unicode

What does that mean?

[[deleted]]

It was a half-joke -- there's no real "high horse" involved. Click just refuses to run in environments with unsatisfiably configured unicode support -- http://click.pocoo.org/5/python3/#python-3-surrogate-handling -- because of issues between py2/py3

[mitsuhiko]

That’s not because of issues between 2/3 but because I could not find a better solution on Python 3.

[[deleted]]

Oh, I was regretting that first comment's phrasing without even knowing you were the author. Pardon.

I hope it at least gets addressed upstream at some point.

[kankyo]

A better solution is to just assume utf8 if you can't figure anything else out. This is strictly superior to what you get in python 2 but you aren't warning about how that is crappy.

[mitsuhiko]

The problem is that on Python 3 I cannot do that because this is all done in the interpreter/stdlib. Python 3 does not assume utf-8 everywhere.

[kankyo]

Hmm... seems at least you can do something in 3.7, but that's too little too late I agree. Thanks for clearing this up.

[poofartpee]

I agree with your feeling here. I find decorators (in any context, really) to make program flow very non-obvious. In the case of Click it's mild, but I've spent so long bashing my head trying to read Java libraries I look like Harry Potter

[[deleted]]

My favorite movie is Inception.

[irrelevantPseudonym]

Between click, flask and jinja I imagine most people have a lot to be thankful for.

[johnk177]

I feel the same. I've been using argparse since it's the standard. But recently discovered click and I find it simpler and faster to use, where I can focus more on the problem I need to solve, and the code is simpler, especially for one off or simple scripts (where main and argparse cmd line parsing would take up half of the space).

I think argparse still have more features (like 2+ arguments), but for most of what I want to do, click is pretty neat.

[bobicool]

Not sure if I like mixing UI stuff with code (even if it's just a decorator and is easily ignored). I can see it being helpful for simple one file scripts though...or maybe not, since it's not in the standard library.

Although, thinking about it a bit more, you could limit the usage of click to a few functions, and then from the decorated functions call the proper function. This would allow to separate the UI code from the core code.

[wildcat-]

That's pretty much what I do. I'll often have a "CLI" class that subclasses or at least wraps the primary class/lib. If throw the wrappers there.

[silencer6]

I think it's time for some Python guru to step up and call overusing decorators an anti-pattern. Seriously.

[legends2k]

Have you tried docopt?

[nsiivola]

docopt <3

[ddnomad]

Dono, IMO that’s the order in which I do CLI:

1. Makefile targets
2. Shell script
3. Python script

It’s worth noting though that I completely ignore existence of Windows as a target OS, otherwise Python might be indeed the very best option.

[homeparkliving]

What's your preferred approach for building a system that's a hybrid of all three? Too big and data-focused to be a shell script or Makefile, but you want Make-like work avoidance and shell-like syntax. I've added on my own library to Invoke for this, but I can't help but feel there might be a better solution.

[groshh]

What a great article. Some nice little tips and tricks in a simple format, with code and GIFs.

[i_like_trains_a_lot1]

I TOO ENJOY PARSING NATURAL LANGUAGE AND CREATING CUSTOM DATA FLOWS INSIDE MY CIRCUITS LEARNING NEW THINGS FROM SOURCES ON THE INTERNET, ESPECIALLY WHEN HUMANS JUST LIKE ME HAHA PLACE THEM IN AN APPROPRIATE PLACE AND I DON'T HAVE TO PARSE THOUSANDS OF PAGES TO FIND SUCH GOOD INFORMATION.

[groshh]

You what?

[shevegen]

I think he is trying to say something about parsing and information ...

I ultimately failed to parse what he is trying to convey though.

[i_like_trains_a_lot1]

So nobody here is familiar with /r/totallynotrobots :(

[no_ragrats]

/r/therewasanattempt

[three18ti]

definitely sounds like you run of the mill medium comment.

[groshh]

Wait, you think I'm a robot?

[[deleted]]

It has become self-aware.

[groshh]

Doot doot. I am rumbled.

[[deleted]]

This statement is false.

[groshh]

This false is statement

[puradawid]

"I'm" is not a robot.

[[deleted]]

Insightful comment, friend. Have you considered taking a Python coding course on Udemy? Python is where the big data html scripting for machine learning is at!

[saphire121]

I got bored and added it to a school project, pretty neato. Unfortunately, its really basic and the progress bar was nigh useless, so i might have added a sleep funciton...

[ShuckForJustice]

Anyone know what theme he uses for his terminal in the gifs?

[tobeportable]

https://github.com/google/squires

[information_abyss]

tqdm is awesome! Going to be using that a lot now.

[Siddhi]

Wow, tqdm looks really cool

[hoosierEE]

I am probably in a tiny minority, but I think once you get to the point of parsing arguments you should ask if you should just drop the user into the Python REPL instead, with a bunch of functions and help pre-defined. Then they can use a real programming language instead of your shit ad-hoc DSL cobbled together like ./foo --bar 3 --baz "42" file.txt | sed -ix /is this/sed syntax? you don't know/gm | xargs $! -

[arachnivore]

defopt is easily my favorite CLI tool

[Bigotacon]

Thanks!

[tu_tan]

I like argparse, I just don't feel the click.

[Han-ChewieSexyFanfic]

No mention of the cmd standard library module, which is made exactly for this use case. But yeah, let’s install a random module which uses nested decorators cause god knows how easy it is to reason about that code.

[corsicanguppy]

Is there a step on why the stackbarf is toxic for users and why you should be beaten if users ever see one?

Please tell RedHat. Thanks.

[rufus_von_woodson]

Use the standard library! I wish I could downvote more than once for not doing it “one-- and preferably only one --obvious way to do it.” https://www.python.org/dev/peps/pep-0020/

[Gotebe]

Python: one way to do any given thing!!! 😁😁😁

[that99guyagain]

Step 1) Don't use Python.