Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Click – Python library for command-line interfaces

click.pocoo.org

Post reply on HN
Print view View original

81–90 of 105 posts

Re: Click – Python library for command-line interfaces

#81

Post by zokier »

Serow225 wrote: post #45
thu wrote: post #17

The biggest gripe I have with using Python for rich command-line tool is the startup time. One of the first reason I like to write a nice command-line tool when I start a project, say foo, is to be able to do `foo --help` to quickly see and remember what the project can do (I have a very bad memory and doing this makes it possible for me to jump back faster to a project, even well documented. I can forget what I was…

I'm completely clueless about this, but would it be possible to have a persistent python interpreter always running in the background somehow, and submit the commands to it?

You can keep ipython kernel running in background if you want. Quick unscientific test showed that it didn't reduce ipython console startup time significantly. But it should be possible to make a leaner console to connect to the kernel.

edit: my test was flawed, with more accurate test there is almost a full second time difference:

    $ echo -n | time ipython console --existing kernel-29793.json
    1.06user 0.06system 0:01.52elapsed 74%CPU (0avgtext+0avgdata 29968maxresident)k
    0inputs+64outputs (0major+19245minor)pagefaults 0swaps
    $ echo -n | time ipython console
    1.07user 0.08system 0:02.40elapsed 48%CPU (0avgtext+0avgdata 30264maxresident)k
    0inputs+72outputs (0major+20538minor)pagefaults 0swaps
of course two seconds is ridiculously slow either way

Re: Click – Python library for command-line interfaces

#82

Post by voltagex_ »

aidos wrote: post #14
ramblerman wrote: post #12

Earlier quoted context omitted.

As someone who has never used either, the documentation and simple example of Click won hands down. I could use it for simple cases within 15 seconds of reading. Docopt not so much.

You're right - looking on the http://docopt.org/ page it's not immediately obvious how it works. The general idea is that you don't specify any code, you just give the help message as text. Docopt parses that to figure out all the options etc and convert those into the parameters coming in to your system. It's a really clever idea. You specify the human interface, docopt converts that into the code version (so long a…

That's brilliant. I wonder if there's a way to use docstrings like that to create REST services in Flask.

Re: Click – Python library for command-line interfaces

#83

Post by zhaphod »

parhamn wrote: post #50
hoodoof wrote: post #3

Gorgeous. This guy has a full time job, a wife, and wrote Flask and Werkzeug, ItsDangerous, Sphinx, Markupsafe, Jinja2 (and Jinja) and that's just some of the well known stuff. Handsome and young too. Bastard. He probably saves the world in a dinner jacket in his spare time.

Armin Ronacher is absolutely amazing at python. If you want to learn some things dive into his source code and dig away. He really thinks through code architecture.

I am already on this. Not gonna stop till I read up on all of his code.

Its a plane, its a bird, No its kick ass python programmer. :).

Re: Click – Python library for command-line interfaces

#84

Post by abecedarius »

peterjs wrote: post #28

On a related note. Which python library would you recommend for text-based interfaces? I have never used ncurses, so I don't know how complex it is. What I would like to achieve is having a user launch my script from the command line, use the text based interface to select a source and destination folder, set a few parameters and show a progress bar.

https://github.com/thomasballinger/curtsies looks well-designed. (I haven't tried it yet. What I do is code to ANSI terminal codes directly: e.g. https://github.com/darius/sketchbook/blob/master/misc/sokoba...)

Re: Click – Python library for command-line interfaces

#85

Post by msvalkon »

agentultra wrote: post #46
lftl wrote: post #40

Earlier quoted context omitted.

To be fair he only got married this month, so the jury is still out on where his productivity goes from here ;)

Getting married didn't kill me it was having a kid. Now I get maybe four hours a week for hobby/OSS programming.

This is true. I have two now. Personal time is now a dusty concept.

Re: Click – Python library for command-line interfaces

#86

Post by Cyph0n »

the_mitsuhiko wrote: post #61
lftl wrote: post #40

Earlier quoted context omitted.

To be fair he only got married this month, so the jury is still out on where his productivity goes from here ;)

Given that I wrote parts of this on my honeymoon I think it helped. Fingers crossed :)

You never cease to amaze :D

Re: Click – Python library for command-line interfaces

#87

Post by mixmastamyk »

Cyph0n wrote: post #86
the_mitsuhiko wrote: post #61

Earlier quoted context omitted.

Given that I wrote parts of this on my honeymoon I think it helped. Fingers crossed :)

You never cease to amaze :D

That's actually not a good sign for future marital bliss.

Re: Click – Python library for command-line interfaces

#88

Post by masklinn »

timtadh wrote: post #79
the_mitsuhiko wrote: post #39

I did not expect this to be on hackernews this early. I want to point out that I have not made a release yet and it's not yet feature complete. Mainly I want to ask for feedback on the general design.

Armin, my feedback is in the form of my own version of this library.[1] I have been working on this on and off for some time and like you have not made a release. That said, I have been using it quite a bit both in my research and at work and I think it helps. The main idea behind it is make it easy to write a "getopt" style program with arbitrary command nesting. I have found that although argparse and sisters are n…

> I have found that although argparse and sisters are nice libraries they don't allow me to do many of things I like to do in my interfaces. For instance sometimes like options such as

?

This is trivial to do with argparse (or optparse for that matter):

    import argparse

    def a_prefixed(string):
        if not string.startswith('a'):
            raise argparse.ArgumentTypeError("%r does not start with 'a'" % string)
        return string

    parser = argparse.ArgumentParser()
    parser.add_argument('-x', '--extra', action='append', type=a_prefixed)

    print parser.parse_args()
resulting in:

    > python test.py -x afoo -x abar
    Namespace(extra=['afoo', 'abar'])
    > python test.py -x afoo -x baz
    usage: test.py [-h] [-x EXTRA]
    test.py: error: argument -x/--extra: 'baz' does not start with 'a'
> I also believe that you should have "fast fail" validators.

Isn't that what the callback parameter is for, especially with is_eager=True? Or ParamType if you need either something more reusable or something more extensive.

> Most of the time I deal with files, directories, and "string" parameters which these libraries don't help with.

http://click.pocoo.org/api/#click.File, argparse has something similar.

Re: Click – Python library for command-line interfaces

#89

Post by Tyr42 »

erlkonig wrote: post #75

Why is it that (nearly) every description I read about some random new Python command wrapper fails to get the "python" and ".py" out of the command examples, even in Linux? I don't blame this particular offering, since I don't think release was actually planned just yet and any number of other projects have made the same subtle mistake. Command Name Extensions are Harmful. Don't expose such an implementation detail…

Did you see the last part on setuptools?

It actually shows you how to set it up so you don't even use a #!, but rely on setuptools to make an executable for you, that'll work in a vitualenv or on windows. And the script name doesn't have .py at the end in his example, though he doesn't call that out specifically.

Re: Click – Python library for command-line interfaces

#90

Post by rcthompson »

the_mitsuhiko wrote: post #39

I did not expect this to be on hackernews this early. I want to point out that I have not made a release yet and it's not yet feature complete. Mainly I want to ask for feedback on the general design.

I think the creation of a group by decorating an empty function seems awkward. Why not just have the group be an ordinary class, i.e. something like "cli = click.group()"?
Post reply on HN