Hacker News Reader

Comment by StavrosK | Hacker News Reader

What __foo__ stuff?

__call__; __new__; __getattr__ and __getattribute__; and __metaclass__ - you can do some black magic in Python straight out of the box that takes a lot more work in statically typed languages.

Those are used for hacking, though, or for more advanced usage. The syntax is to discourage trivial use.

I'm not the author, but I believe the classic example is:

if __name__ == "__main__":

Or methods like __init__, __str__, __cmp__, etc. I know they are part of Python's protocols, which are basically a form of the template method pattern, and that they do make sense. But to some people they feel hackish; they woud prefer to have "normal" name methods for these protocols instead.

If they were normal they'd eat up your namespace.

Yes. But, it that a bad thing?

For example, I think if you'd have to explain how to change the string representation of some kind of object, saying "just define the 'str' method and then call it, like 'something.str()'" is simpler than "define a '__str__' method -- don't worry about all the underscores -- but then don't call it directly; instead of that, use the global 'str' function".

I don't know if that extra indirection (i.e. calling 'str', which, in turn, calls '__str__'; or 'next', that calls '__next__' in Python 3) adds more value than the simplicity of not having that extra indirection in the first place.

If it used normal names, Python couldn't evolve new methods for its protocols with language support. It would need some kind of annotation saying “yes I really mean to get this method called by the language and didn't just happen to use the same name by coincidence”.

You don't actually need that though - there is a completely obvious way to write stuff without having to use that line.

Just about the only underscore that you can't really avoid is the constructor syntax, "def __init__()". Which I guess is tolerable.

> You don't actually need that though - there is a completely obvious way to write stuff without having to use that line.

Can you elaborate on that point? I thought that was the canonical way to do exactly that... http://docs.python.org/library/__main__.html. If there's an easier/less verbose method (pun not intended) I'd love to know about it.

From your link:

It is this environment in which the idiomatic “conditional script” stanza causes a script to run

The conditional script stanza is optional, and intended to make a .py file function as both a script and a module (i.e. be importable). To me, it's unclear why you would want to do that. The only thing you have to do to avoid using __main__ is not require any file to be both a script and a module/library. Then just put any entry-point code at the top level of whatever script invokes your program. Unfortunately the __main__ stanza is pretty widely used though.

On the topic of modules, there is a wrinkle in requiring __init__.py to be present in any library subdirectory that you want to be part of the namespace. It would be nice to have a more intuitive way for that.

Oh, I do it all the time. It allows me to write a script that I can just run from the command line when I want, like 'fetch_new_images'.

I especially love it when I'm first coding, cause I like to test as I go. That allows me to run it to see what works and what doesn't.

When I'm finished, I know that I can just plop that file into a directory and use it as a library afterward. The majority of the code that I write implements that, and I find it a godsend, personally.

Reply on news.ycombinator.com