On Wed, 27 Oct 2010 14:02:27 +0000, kj wrote: > I have nothing against humor. The reason why I find "import braces" > funny is that it is so obviously a joke. But I do find it mildly > annoying (and just mildly) that a joke/hoax/farce like ZoP/this.py is > built into the standard lib, because a lot of people (not just me) don't > realize it's a joke.
What makes you think it's a joke? > I don't see the point > of making the task any harder than it already is by injecting additional > *gratuitous confusion* in the form pseudo-rogramming advice that > apparently no experienced Python program really believes/takes seriously > anyway. You're badly misinformed if you think that Python programmers don't take the Zen seriously. I dare say some don't, particularly those who like writing Lisp/Java/PHP/ whatever in Python. I also expect that some take it *too* seriously, as religious dogma. Although the Zen is written in a light-hearted fashion, it is not intended as a joke. Every line in the Zen is genuine advice -- even the one about being Dutch. Would it help to write it out in a less light- hearted fashion? When programming in Python, you should: Aspire to write beautiful, elegant code and algorithms, rather than ugly and messy. Programming is about giving instructions to the computer. It is better to give those instructions explicitly, rather than implicitly based on the context -- context which may not be quite what you expect, or that the reader may not have recognized. Simple code has fewer things to go wrong, less to understand, and fewer places for bugs to hide. Prefer simple code to complex code. Complex problems may require complex solutions. But complicated solutions should be avoided if you can. A watch is complex; the rules of precedence and etiquette in the court of Louis the Sun King in 17th century France were complicated. Flat data structures are typically easier and faster to parse, and should be preferred over nested data structures. Where you need nested data structures, prefer shallow rather than deeply nested. You read source code much more often than you write it, and consequently readability of the code is important. Aim to maximize readability unless performance dictates compromising on readability. Languages and libraries should aim for consistency and should support the general case. Resist the temptation to pile on support for special cases that are useless for nearly everybody. Let the caller handle their own special cases in their code. Unless there are good, practical reasons for supporting a special case. Errors should be treated as errors. Library code should always report errors that occur, and not just silently suppress them. Users should have the option to explicitly silence errors they don't care about. If a situation is ambiguous, functions should not try to guess what the caller meant. They will sooner or later get it wrong. For each task the user wants to do, there should be an obvious way to do it. Preferably only one obvious way, but multiple solutions are allowed. If there is no obvious way at all, then the language or library is lacking. Sometimes what is obvious to Python's designer, Guido van Rossum, who is Dutch, may not be obvious to anyone else who doesn't share his background. Live with it. If something needs doing, it is better to do it now than to procrastinate and never get it done. Don't wait for software to be perfect -- you can measure many things with a ruler with a notch in the side, and even a blunt saw cuts better than no saw at all. But sometimes it is better to do without than to lock yourself into a faulty standard. If there's no solution that's good enough right now, it may be better to wait for one than to be stuck forever on a bad solution. If the implementation of software is complicated and hard to explain how it works, it is probably a mistake to go down that path. Find a better implementation. If the implementation is simple and easy to explain, it may be a good idea. But some ideas are just bad, regardless of whether they are easy to implement or not. Namespaces are a tried and tested solution to many programming jobs. We should use them more often in Python. 535 words instead of 137. I prefer the Zen. You'll note that some of the maxims are general rather than specific to Python. Some might argue that *all* the maxims are perfectly general, and the fact that other languages make other choices is their loss. -- Steven -- http://mail.python.org/mailman/listinfo/python-list