Hacker News Reader

Comment by tghw | Hacker News Reader

The first Python example throws up a big red flag: manually parsing command line arguments instead of using argparse. Why reinvent the wheel when there is a standard library to handle it?

Likewise, asserting that "For storing general records, Python provides a choice of classes and tuples" completely ignores one of Python's fastest and most powerful data types: dictionaries.

Lastly, in get_value, the nest of ifs is unnecessary and makes the code seem more complex than it really is.

View on HN

Over the last decade, there's probably been half a dozen "standard" command line parsing tools. getopt being the classic, then we had optparse and that got deprecated, then we got argparse. And there there's e.g. twisted.usage and the pretty cool docopt.

In this case the author wants to parse "program <foo | bar | baz> [optional args]" and does that in a few lines of code. You seriously think that's a "big red flag" ?

Do you also believe the author does not (despite having created the zero install tool 10 years ago) know Python has dictionaries?

This is a blog post where the author evaluates a number of languages/environment to replace his particular Python needs -- do you think that him not using a new standard library module invalidates his finding?

I like this article on that subject, which as it happens uses argument-parsing as the running example: http://www.yosefk.com/blog/redundancy-vs-dependencies-which-...

We've had optparse since at least 2003; programs that don't use standard tools to parse their command lines usually have lame bugs such as not responding properly to "--help" (must do nothing but write to stdout and return 0 on *nix).

I'm not the one who first mentioned that hand-written option parsing is a red flag. But it is one--especially in Python, which has nice things built in.

The actual 0install Python code does use optparse.

It wasn't stated in the post, but the next step after writing this code was to use it as a front-end to the real Python version. If invoked as "0install run NAME ARGS..." exactly then we handle it (the fast path), otherwise we fall back to the Python version. In particular, that means that the Haskell/OCaml version must NOT try to handle --help, etc. I wrote the comparison Python code to be similar to the other languages.

This OCaml front-end appeared in 0install 2.3. For 0install 2.4 there is a full option parser written in OCaml. I didn't use a library for this because a) it needs to be 100% compatible with the Python parsing and b) it needs to handle tab-completion too.

In his defense, the author makes the following disclaimer:

"As before, note that I’m a beginner in these languages."

He was referring to all of the other languages. In his previous article, he writes:

"I’m not an expert in these languages (except Python)."

There are many examples of archaic/non-idiomatic/gross Python. Old-style classes, unnecessary cyclomatic complexity, and so forth. Using Python effectively (i.e. expertly) means wantonly abusing hash tables, generators and its functional paradigms.

I was under the impression that using a class (with `__slots__` set) or a tuple is generally more performant than using dictionaries. At least, I assume that's why he didn't mention dictionaries.

The attributes of an object (and its class) are generally stored in a literal dictionary, so it's unlikely that a class will be more performant.

What a class buys you is behavior and a semi-defined interface.

Uhh... Did you not see my parenthetical reference to `__slots__`? See this SO post[1] for more details.

[1] - http://stackoverflow.com/questions/472000/python-slots

Whoops! I could've sworn that said "without", sorry :)

Though I'm not sure `__slots__` actually saves any time, as it's really a space optimization. I've tried it before for hot code and even seen very slight (probably not significant) slowdowns.

Reply on news.ycombinator.com