by Richard Jones
aka 19 Pythonic Theses
See http://en.wikipedia.org/wiki/Euclidean_algorithm:
function gcd(a, b)
while b ≠ 0
t := b
b := a mod b
a := t
return
Wikipedia’s version is not as pretty as Python:
def gcd(a,b):
while b != 0:
a, b = b, a % b
return a
File openings are not that explicit
The : in Python is lovely and explicit.
class Circle(object):
def __init__(self, radius):
self.radius = radius
def area(self):
""" The 'tau' value is from outside the class """
return tau * self.radius
Getting length of objects is simple in python:
l = [1,2,3,4,5,6,7,8]
len(l)
Try to keep your try/except blocks a small as possible. You’ll thank yourself later.
Note
I never actually think about this koan.
for line in open('document.txt'):
print(len(line), line, end='')
# how about opening up things
for file in glob.glob('*.txt.gz'):
for line in gzip.
Keep object inheritance shallow
Multiple inheritance keeps things shallow but things get more complex
- Richard Jones worries about this
- I don’t worry that much. Never bites me the way Java did.
Is this a style guide thing?
- whitespace?
- naming standards
I (pydanny) think it is about spartan programming
Koans by Tim Ansell
- 14 arguments for a method is too much
- Don’t compromise on complexity by adding more complexity
if (x == y);
{
// logic
};
// a day wasted
Sometimes the rules need to be broken:
>>> class Two(int):
... pass
...
>>> print(Two(1))
1
>>> Two.__str__ = lambda x: '2'
>>> print(Two(1))
2
A better example is circular imports.
Errors should not be fatal
Don’t blame the user for bugs in Python
- Either the core devs fault
- Or the user added in ctypes
logging.exception(error) captures the entire error to the logs!
try:
handle_a_client()
except socket.error, e:
log.warning('client went away: %s', e)
except Exception, e:
logging.exception(e) # This captures the whole traceback!!!
1 + '1'
# blows up in Python, not in other languages
# We like this behavior!
Also, remove the ambiguity and whack some parenthesis
Protocols:
- File API
- DB API
- WSGI
- etc
You try to shoot yourself in the foot, only to realize there’s no need, since Guido thoughtfully shot you in the foot years ago. - TODO: find who said that
Things that ain’t gonna happen
- Adding ‘?’ to identifiers in Python
If you can’t say it, don’t do it
Just because you can explain your idea, if it has no point then it shouldn’t be included.
>>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than right now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!