This article isn't as much about one-liners as it is about the usefulness of the if __name__ == '__main__' idiom. It's great when a module can be consumed as a library and as a command-line script at the same time.

Unfortunately, Python isn't really that good for writing one-liners, especially those that process input. At one point I was sufficiently unhappy about this, that I tried doing something about it:

    https://github.com/gvalkov/python-oneliner

It also looks like this was just for self-reference; it's not an article as it is a collection of useful tips.

I write a lot of these to remind myself of tool usage.

Most of these should be tools of last resort, the technological equivalent knowing how to start a fire without matches. The performance of SimpleHTTPServer is abysmal, particularly if you want to serve a few files over 100MB or thousands of little files.

Even toy webservers blow the Python versions away. If I need a quick one-off server to share files over the LAN, webfs [1] is first on the draw. 90% of my uses don't even need fiddling with the command options. Though webfs is fairly limited, SSL is the most complicated thing it can do.

For slightly more advanced one-off webservers, thttpd [2] is wonderful. It's got many of the features of heavy duty webservers (plus great throttling controls) but every option is tune-able from the command line.

And as an aside, my own jshon [3] is usually nicer and faster than mjson.tool, at least until you hit a fairly high level of complexity.

[1] http://linux.bytesex.org/misc/webfs.html

[2] http://www.acme.com/software/thttpd/

[3] http://kmkeen.com/jshon/

edit: Thanks dschep.

It's useful for quickly getting an HTTP server. No one in their right mind would use it for anything more. There are plenty of other very good python web servers.

I am arguing it is not even useful for that. If you simply want to share files across a LAN (the use case for these oneliners), SimpleHTTPServer falls flat on its face. It'll transfer large files at DSL-like rates and time out completely on directories with large numbers of files in them.

What are you supposed to do with an http server after getting one quickly? Stare at the open port? The only thing quick about SimpleHTTPServer is the startup time. Don't actually try using the server.

The specific instance that put me off of the python servers was when a friend downloaded a CableGate tarball and someone else wanted to look at it. No one had a flash drive on them, but the fellow did have python installed. One SimpleHTTPServer later and the tarball was being transferred at 100KB/sec, slower than the original download. The cables were all html anyway so let's try uncompressing the tarball and serving those. Now the server would time out instead.

What do people actually use SimpleHTTPServer for?

I'm using it right now to serve up HTML files which I'm testing my (python) screen scraper on.

It means I can develop offline.

> What do people actually use SimpleHTTPServer for?

I've used it as a half-baked and very short-lived file-sharing mechanism before, similar to what you describe above. I haven't noticed the DSL-like transfer rates because my broadband ISP gives me dialup-like upload speeds.

One thing I use it for often is serving HTML so I get the correct origin in browsers. Some development servers are also based on it.

Yes, it's terrible. But not useless.

> What do people actually use SimpleHTTPServer for?

Smaller files than you need to move around when using a 1 off http server.

It's a good HTTPD Dummy. I've mostly used it in debugging purposes - a little as a swiss army knife.

It's not that useless that you're portraying it as. But I do however agree that it's below toy level. It's not for production or long-time use.

Yeah, it does seem a little useful for lightweight development and testing. Though I find it bizarre that anyone doing professional web development can't spare the 1MB for an Nginx or Lighttpd install.

When developing Javascript apps locally, I often use SimpleHTTPServer so I can access them through http:// rather than file:/// URLs, which tend to interact badly with the same-origin policy.

For your 1st example and last example, the python builtins have the huge advantage of already being installed on most [linux(mac?)] boxes.

Note, you missed the "l" on the end of link [1]

>SimpleHTTPServer

I have stopped using tools like that and even XAMPP. There's always something to mess you up. These days I just boot an instance of Ubuntu 12.04 Server on a virtual machine and life is beautiful. The next move is to setup a spare PC with, add an internal DNS server and route all *.local domains to said local Linux server.

you can smash my head with a hammer (preferably double clawed), but I can't help myself:

        php -S localhost:8080

10 chars typing effort spared, and it also supports ...PHP :P

There are a few scripts that facilitate the use of python on the command line:

https://gist.github.com/dgulino/4750088 (mine)

http://code.activestate.com/recipes/437932-pyline-a-grep-lik...

Kind of related:

cat messy.json | python -mjson.tool

This is one of the examples in the article.

So, if I had spent the time used to create a HN account on reading the article another time, I wouldn't have to feel this stupid...

It's worth noting that this doesn't retain ordering

Related: http://www.pixelbeat.org/programming/evanescent_python.html

In article I focused on usefulness of python one liners regardless of what technology they use. This one more for python devs.

I recently wrote PAWK (https://github.com/alecthomas/pawk) in order to give me Python at the command line. It's exactly what you think it is: Python AWK.

It's served me well so far.

Also, the last line to check for 'one-liners' won't get them all:

  $ grep -r  "if __name__ == '__main__'" /path/to/lib

Should be:

  $ grep -r  "if __name__ == ['\"]__main__['\"]" /path/to/lib

If you're not storing that somewhere, but rather typing it, I find you're often better off by being a little more forgiving, eg:

  $ grep -r "if __name__ == .__main__." /path/to/lib

or even: $ grep -Er 'if\W__name__\W==\W.__main__.'

You could also do this:

    grep -n __main__ *.py|grep __name__

which turns up few false positives.