Python quotes 19.02.2010

Есть такой замечательный ресурс Python Quotes - 10 страниц отборных цитат из переписки в python-dev, вот некоторые из них:

This is Python! If we didn’t care what code looked like, most of us would probably be hacking in some version of Lisp – which already covered most of Python’s abstract semantics way back when Guido was just a wee snakelet frolicking in the lush Amsterdam jungle.
Tim Peters, 24 Apr 1998

“However, I’ve heard that after about 10K items in a dict, it starts having problems.” “11,523 to be exact. After that, dicts drink to excess and show up for work late the morning after. We don’t like to talk about it, though.”
Aahz Maruch and Tim Peters, 8 Jun 1999

here’s the eff-bot’s favourite lambda refactoring rule:
1) write a lambda function
2) write a comment explaining what the heck that lambda does
3) study the comment for a while, and think of a name that captures
the essence of the comment
4) convert the lambda to a def statement, using that name
5) remove the comment
Fredrik Lundh, 01 Apr 2001

The static people talk about rigorously enforced interfaces, correctness proofs, contracts, etc. The dynamic people talk about rigorously enforced testing and say that types only catch a small portion of possible errors. The static people retort that they don’t trust tests to cover everything or not have bugs and why write tests for stuff the compiler should test for you, so you shouldn’t rely on only tests, and besides static types don’t catch a small portion, but a large portion of errors. The dynamic people say no program or test is perfect and static typing is not worth the cost in language complexity and design difficulty for the gain in eliminating a few tests that would have been easy to write anyway, since static types catch a small portion of errors, not a large portion. The static people say static types don’t add that much language complexity, and it’s not design “difficulty” but an essential part of the process, and they catch a large portion, not a small portion. The dynamic people say they add enormous complexity, and they catch a small portion, and point out that the static people have bad breath. The static people assert that the dynamic people must be too stupid to cope with a real language and rigorous requirements, and are ugly besides. This is when both sides start throwing rocks.
Quinn Dunkan, 13 Jul 2001

Changing diapers reminded Guido that he wanted to allow for some measure of multiple inheritance from a mix of new- and classic-style classes.
Tim Peters in a checkin message, 14 Nov 2001

The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code – not in reams of trivial code that bores the reader to death.
GvR, 20 Mar 2002

Here’s another technique that is faster and more obvious but that is often avoided by those who mistakenly believe that writing two lines of code where one might do is somehow sinful.
Tim Peters, Python Cookbook

A fruitful approach to problem solving is known as “divide and conquer”, or making problems easier by splitting their different aspects apart. Making problems harder by joining several aspects together must be an example of an approach known as “unite and suffer!”
Alex Martelli, Python Cookbook

compromise-is-the-art-of-spreading-misery-ly y’rs
Tim Peters, 11 Dec 2002

comments powered by Disqus