import this

Write Better Python
With Style and Grace

Nick Borko
Chief Technology Officer
Leaning Forward Technologies, LLC

May 14, 2013

Except where otherwise noted, this work is licensed under
http://creativecommons.org/licenses/by-nc-sa/3.0

Agenda

Introduction
PEP 20 — The Zen of Python
Adhering to Style: PEP 8
Python or Pascal?
Python is Object Oriented: Use Classes!
- What do classess look like?
- Public, Internal or Private?
- Special Methods
- What about modules?
- Exceptions
Running Scripts
Putting It All Together

Who Am I?

Currently the CTO of Leaning Forward Technologies
Past Jobs: U.S. Air Force, Booz-Allen & Hamilton, Rackspace
Using Python for serious projects for 15+ years
- Rackspace ERP (CORE) and ticketing (CATS) systems
- Python Servlet Engine web framework (EOL)
- Shareable Content Object Reference Model (SCORM, IEEE 1484.11) Learning Management System (LMS)

PEP 20 — The Zen of Python

PEP - Python Enhancement Proposal
"Easter Egg" in Python

Python 2.7.3 (default, Sep 26 2012, 21:53:58) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 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!
>>>

PEP 20 — The Zen of Python

Beautiful is better than ugly.

def evens(number_list):
    return [ i for i in number_list if i % 2 == 0 ]

rather than:

evens = lambda n:filter(lambda x:not x%2,n)

PEP 20 — The Zen of Python

Explicit is better than implicit.

def area_rect(width, height):
    return width * height

rather than:

from operator import *

def area_rect(*arg):
    return reduce(mul, arg[0:1])

PEP 20 — The Zen of Python

Simple is better than complex.

import json

def pretty_print_dict(d):
    print(json.dumps(d, sort_keys=True, indent=4))

rather than:

import sys

def pretty_print_dict(d, indent=0):
    for key in sorted(d.keys()):
      sys.stdout.write(' ' % indent)
      sys.stdout.write('%s: ' % key)
      if isinstance(d[key], dict):
          pretty_print_dict(d[key], indent + 4)
      else:
          sys.stdout.write(str(d[key]) + '\n')

PEP 20 — The Zen of Python

Complex is better than complicated.

def dispatch_request(request, param1=None, param2=None):
    if request == 'COMMAND1':
        return comand1()
    elif request == 'COMMAND2':
        return command2(param1)
    elif request == 'COMMAND3':
        return command3(param1, param2)

rather than:

def dispatch_request(request, *arg):
    return {'COMMAND1':command1, 'COMMAND2':command2, 'COMMAND3':command3}[request](*arg)

PEP 20 — The Zen of Python

Flat is better than nested.

def type_of_number(number):
    result = []
    if number == 0:
        return 'ZERO'
    if number > 0:
        result.append('POSITIVE')
    else:
        result.append('NEGATIVE')
    if number % 2:
        result.append('ODD')
    else:
        result.append('EVEN');
    return ' '.join(result)

rather than:

def type_of_number(number):
    if number > 0:
        if number % 2:
            return 'POSITIVE ODD'
        else:
            return 'POSITIVE EVEN'
    elif number < 0:
        if number % 2:
            return 'NEGATIVE ODD'
        else:
            return 'NEGATIVE EVEN'
    else:
        return 'ZERO'

PEP 20 — The Zen of Python

Sparse is better than dense.

def factorial(number):
    if number < 1:
      raise ValueError(number)
    elif number > 1:
      return factorial(number - 1) * number
    else:
      return number

rather than:

def factorial(number):
    if number<1:raise ValueError(number)
    else:return factorial(number-1)*number if number>1 else number

PEP 20 — The Zen of Python

Readability counts.

def full_name(first_name, last_name):
    return ' '.join([first_name, last_name])

rather than:

def fln(fn, ln):
    return '%(fn)s %(ln)s' % locals()

PEP 20 — The Zen of Python

Special cases aren't special enough to break the rules.
Although practicality beats purity.

sort(people, lambda person1, person2: cmp(person1.name, person2.name))

rather than:

def person_comparator(person1, person2):
    if person1.name < person2.name:
        return -1
    elif person1.name > person2.name:
        return 1
    else:
        return 0

sort(people, person_comparator)

PEP 20 — The Zen of Python

Errors should never pass silently.
Unless explicitly silenced.

def list_operation(l):
  if len(l) == 0:
      raise ValueError
  else:
    ...do some operation, possibly returning an empty list...

try:
  result = list_operation(my_list)
except ValueError:
  # it's alright if the list is empty...
  result = []

rather than:

def list_operation(l):
  if len(l) == 0:
      return []
  else:
    ...do some operation, possibly returning an empty list...

result = list_operation(my_list)

PEP 20 — The Zen of Python

In the face of ambiguity, refuse the temptation to guess.

if (a & (1<<3)) or (a & (1<<5)):

rather than:

if a & 1<<3 or a & 1<<5:

(although both are equivalent in Python, operator precedence differs in C)

PEP 20 — The Zen of Python

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.

As in perl, there is always more than one way to do it
Be mindful of Python's capabilities:
- less used builtins (cmp, enumerate, min and max for iterables)
- functional constructs (list comprehensions, generators, iterators)
- special language features (decorators,metaclasses)>
While it might not be obvious at first that your problem can be solved by a simple one-liner, consider that there might be an easier, Pythonic way of doing it

PEP 20 — The Zen of Python

Now is better than never.
Although never is often better than right now.

with open('input.txt') as f:
    line = f.readline().strip()
    assert line != "" # no empty lines!

rather than:

f = open('input.txt')
f = readline().strip()
assert line != "" # no empty lines!

PEP 20 — The Zen of Python

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.

def dispatch_request(request, param1=None, param2=None):
    if request == 'COMMAND1':
        return comand1()
    elif request == 'COMMAND2':
        return command2(param1)
    elif request == 'COMMAND3':
        return command3(param1, param2)

rather than:

def dispatch_request(request, *arg):
    return {'COMMAND1':command1, 'COMMAND2':command2, 'COMMAND3':command3}[request](*arg)

PEP 20 — The Zen of Python

Namespaces are one honking great idea -- let's do more of those!

import sys
...
sys.exit(0)

rather than:

from sys import exit
...
exit(0)

and never:

from sys import *

Adhering to Style: PEP 8

PEP 8 (Style Guide for Python Code) was adapted from Guido van Rossum's Python Style Guide essay (also see PEP 257, Docstring Conventions)
Intended to improve code readability: "Readability counts."
Consistency is more important than strict adherance to PEP 8
Knowing when not to follow style guidelines is just as important:
- Strict PEP 8 style would make your code less readable
- Company/Organizational style may break PEP 8 rules
- Surrounding code uses a different style

Python or Pascal?

Pascal is an imperative (and procedural) programming language
- Designed to teach structured analysis and programming
- The basic component is the PROCEDURE (or FUNCTION)
- Programs are sequences of compoents

Example program:

program Fibonacci;

(* Print a Fibonacci series up to n *)
procedure fib(n:integer);
    var a,b,temp:integer;
begin
    a := 0;
    b := 1;
    while b < n do
    begin
        writeln(b);
        temp := a;
        a := b;
        b := b + temp;
    end;
end;

begin
  (* print the fibonacci sequence up to 2000 *)
  fib(2000);
end.

Python or Pascal?

Python is an object oriented (mostly) programming language
- Python is also a structured language (blocks, conditionals, loops, etc.)
- The basic component is the object
- Programs are statements that maniuplate objects
Unfortunately, most Python tutorials and examples teach procedural programming rather than object oriented programming.

Example program (from the Python manual):

def fib(n):
    """Print a Fibonacci series up to n."""
    a, b = 0, 1
    while b < n:
        print(b)
        a, b = b, a+b
 
# print the fibonacci sequence up to 2000
fib(2000)

Python is Object Oriented

Use Classes!

Python is built on objects:
- The number 5 is an object
- The string "Hello, world" is an object
- The type int is an object
- A function defined with def is an object
If you're not programming with classes, you're programming with globals!

Python is Object Oriented

What do classes look like?

A point on a cartesian graph can be represented as a tuple, (x, y)

A point module may have the following function (among others):

def distance_from_origin(point):
    """Calculate the distance from the origin (0, 0) to the point""
    x, y = point
    return ((x ** 2) + (y ** 2)) ** 0.5

Python is Object Oriented

What do classes look like?

As a class:

class Point(object):
    """Point class for tracking points on a 2d graph."""

    def __init__(self, x=0, y=0):
        """
        Constructor arguments:
        x: The x coordinate of the point (default: 0)
        y: The y coordinate of the point (default: 0)

        """
        self._x = x
        self._y = y

    def __str__(self):
        """Return the string representation of the point as (x, y)"""
        return '(%d, %d)' % (self._x, self._y)

    def distance_from_origin(self):
        """Calculate the distance from the origin (0, 0) to the point"""
        return ((self._x ** 2) + (self._y ** 2)) ** 0.5

Python is Object Oriented

Public, Internal or Private?

Python has no notion of member visibility — all class members are public
By convention, variables prefixed with a single underscore (_) are "internal"
By convention, variables prefixed with double underscore (__) are "private" (and mangled)
Use these conventions when writing your classes so others will understand your intentions

Python is Object Oriented

Special Methods

Pythonic implementation of "operator overloading"
Special method names start and end with double underscores (__)
Do not use this convention for any of your own variables/methods
Examples:
- __init__ – Constructor
- __del__ – Destructor
- __str__ – Return a string representation (e.g. via str())
- __getattr__ – Called when looking up an attribute value on the object

Python is Object Oriented

What about modules?

Modules are a kind of encapsulation for structural organization:

A module is an executable block of code — file = module
Modules define common classes/functions/constants as a single object
All objects defined or imported into a module are "global" to the module
Statements are executed when the module is imported (or when used as a script)

Python is Object Oriented

What about modules?

Why shouldn't you rely on modules for data encapsulation:

Code is executed only once: the first time the module is imported
Modules are singleton objects — change any module data, you change it everywhere
Testing, mocking and other frameworks are more difficult to implement for modules than classes

Python is Object Oriented

Exceptions

There are some notable exception when writing modules is better than writing classes:

Writing a library of utility functions
Quick scripts for one-and-done jobs (e.g. system administration)
Using most web frameworks that rely on global state information:
- Request and response objects (among others) are often globals
- Routing (OOTB) doesn't understand how to route methods

Python is Object Oriented

How do you know if you should be using classes? Look for the following signs:

Making use of global data
Repeated passing of data to module functions
Managing your own state information for common data structures
Using copies of modules to avoid tainting internal variables

Running Scripts

Executing a Python script will execute all code in the global scope
Importing a script/module will also execute all code in the global (module) scope
Use the following idiom to make your code importable, but also executable:
```
if __name__ == '__main__':
    ...your executable code...
```
(at the bottom of the module)

Putting It All Together

Hangman Example

Script example
hangman_game.py

Module based example
hangman_module.py

Class based example
hangman.py

Available on GitHub:

This presentation: http://nborko.github.io/python-import-this/
Source code: https://github.com/nborko/python-import-this/

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

import this

Write Better PythonWith Style and Grace

Agenda

Who Am I?

PEP 20 — The Zen of Python

PEP 20 — The Zen of Python

Beautiful is better than ugly.

PEP 20 — The Zen of Python

Explicit is better than implicit.

PEP 20 — The Zen of Python

Simple is better than complex.

PEP 20 — The Zen of Python

Complex is better than complicated.

PEP 20 — The Zen of Python

Flat is better than nested.

PEP 20 — The Zen of Python

Sparse is better than dense.

PEP 20 — The Zen of Python

Readability counts.

PEP 20 — The Zen of Python

Special cases aren't special enough to break the rules. Although practicality beats purity.

PEP 20 — The Zen of Python

Errors should never pass silently. Unless explicitly silenced.

PEP 20 — The Zen of Python

In the face of ambiguity, refuse the temptation to guess.

PEP 20 — The Zen of Python

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.

PEP 20 — The Zen of Python

Now is better than never. Although never is often better than *right* now.

PEP 20 — The Zen of Python

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.

PEP 20 — The Zen of Python

Namespaces are one honking great idea -- let's do more of those!

Adhering to Style: PEP 8

Python or Pascal?

Python or Pascal?

Python is Object Oriented

Use Classes!

Python is Object Oriented

What do classes look like?

Python is Object Oriented

What do classes look like?

Python is Object Oriented

Public, Internal or Private?

Python is Object Oriented

Special Methods

Python is Object Oriented

What about modules?

Python is Object Oriented

What about modules?

Python is Object Oriented

Exceptions

Python is Object Oriented

Running Scripts

Putting It All Together

Hangman Example

Write Better Python
With Style and Grace

Special cases aren't special enough to break the rules.
Although practicality beats purity.

Errors should never pass silently.
Unless explicitly silenced.

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.