Python Worst Practices

Python Worst PracticesDaniel Greenfeld

Daniel Greenfeld@pydanny

I do cartwheelsDaniel Greenfeld (@pydanny)

Pythonista at Cartwheel

Djangonaut at Revsys

Co-lead of Django Packages &

Open Comparison

Learned Python at NASA

Fiancé of Audrey Roy

Talk Format

• At least one ‘Python Worst Practice’ slide

• At least one ‘Fixed Python Practice’ slide

• A side-by-side comparison slide

Each section will have three components:

These slides are already online!

Warning!

Don’t use the‘Python Worst Practices’

examples in your code*

You may be hunted down and killed

*Sometimes these are caught byvarious code checking tools

Advice!

Do consider using the‘Fixed Python Practices’

examples in your code

You may get complimented

Fundamentals

Python Worst Practiceobject = MyObject()map = Map()zip = 90213 # common US developer mistakeid = 34 # I still fight this one

I’m guilty

• I still use ‘id’ when I shouldn’t

• I admit I have a problem

• That gives me license to pick on others

Fixed Python Practiceobj = MyObject() # necessary abbreviationobject_ = MyObject() # Underscore so we don't overwrite

map_obj = Map() # combine name w/necessary abbreviationmap_ = Map()

zip_code = 90213 # Explicit name with US focuspostal_code = 90213 # i18n explicit namezip_ = 90213

pk = 34 # pk is often synonymous with idid_ = 34

Side-by-side comparison

object = MyObject()map = Map()zip = 90213 # common US developer mistakeid = 34 # I still fight this one

obj = MyObject() # Use a necessary abbreviationobject_ = MyObject() # Use underscore so we don't overwrite

map_obj = Map() # combine name with necessary abbreviationmap_ = Map()

zip_code = 90213 # Explicit name with US focuspostal_code = 90213 # International explicit namezip_ = 90213

pk = 34 # pk is often synonymous with idid_ = 34

Worst Practice Fixed Practice

Python Worst Practice

true = 0false = 1True = False

Flipping the booleans

Usually done to support an API

This sort of APIdef crazy_posting_api(value): """ If a value is supplied

successfully return ‘0’. Otherwise return ‘1’ """ if value: return 0 return 1

Fixed Python Practiceclass CrazyApiConsumer(object):

def __init__(self, value): self.value = value

def post(self): # fix booleans in/around the return statement response = crazy_posting_api(self.value) return not bool(response)

cac1 = CrazyApiConsumer("hello")print(cac1.post())cac2 = CrazyApiConsumer("")print(cac2.post())

Side-by-side comparisonWorst Practice Fixed Practice

true = 0false = 1True = False

class CrazyApiConsumer(object):

def __init__(self, value): self.value = value

def post(self): # fix booleans in/around the return statement response = crazy_posting_api(self.value) return not bool(response)

cac1 = CrazyApiConsumer("hello")print(cac1.post())cac2 = CrazyApiConsumer("")print(cac2.post())

strColor = "green"boolActive = FalseintPythonYears = 20dtPythonFirstUsed = "04/20/2011"

Identifying variable types with prefixes

Mixing case doesn’t help either

clr = "green"ctv = FalsepythnYrs = 20pthnFrstSd = "04/20/2011"

Conserving pixels by removing the vowels

c = "green"a = Falsep = 20t = "04/20/2011"

Fixed Python Practicecolor = "green"active = Falsepython_years = 20python_first_used = "04/20/2011"

Python assumes we are all consenting adults

• Infer from naming schemes the type/purpose

• Don’t be constrained by type

Fixed Python Practice

The pixel shortage is over. Use reasonably long variable names.

color = "green"active = Falsepython_years = 20python_first_used = "04/20/2011"

strColor = "green"boolActive = FalseintPythonYears = 20dtPythonFirstUsed = "04/20/2011"

clr = "green"ctv = FalsepythnYrs = 20pthnFrstSd = "04/20/2011"

c = "green"a = Falsep = 20t = "04/20/2011"

color = "green"active = Falsepython_years = 20python_first_used = "04/20/2011"

foo = [1, 2, 3]

for i, item in zip(range(len(foo)), foo): print i, item

Don’t use enumerate

Fixed Python PracticeUse enumerate

foo = [1, 2, 3]

for i, item in enumerate(foo): print i, item

• Memorize the Python built-ins

• Makes your code easier to read

• Proven code

foo = [1, 2, 3]

zip(range(len(foo)), foo): print i, item

foo = [1, 2, 3]

for i, item in enumerate(foo): print i, item

Present using

Different Fonts

Dark Text

Dire Backgr#nds

Present using

High ContrastEasy-to-read fonts

All devices offAll programs off

Present using

Different Fonts

Dark Text

Dire Backgr#nds

Present using

High ContrastEasy-to-read fonts

All devices offAll programs off

Classes

Python Worst PracticeImplementing Java-style getters and setters

import logginglog = logging.getLogger()

class JavaStyle: """ Quiz: what else am I doing wrong here? """

def __init__(self): self.name = ""

def get_name(self): return self.name

def set_name(self, name): log.debug("Setting the name to %s" % name) if isinstance(name, str): self.name = name else: raise TypeError()

if __name__ == "__main__": j = JavaStyle() j.set_name("pydanny did this back in 2006!") print(j.get_name())

Fixed Python PracticePython properties!

class PythonStyle(object):

def __init__(self): self._name = ""

@property def name(self): return self._name

@name.setter def name(self, value): """ Because name is probably a string we'll assume that we can infer the type from the variable name""" log.debug("Setting the name to %s" % value) self._name = value

if __name__ == "__main__": p = PythonStyle() p.name = "pydanny doing it the right way" print(p.name)

Accessor

Mutator

class JavaStyle: """ Quiz: what else am I doing wrong here? """

def __init__(self): self.name = ""

def get_name(self): return self.name

def set_name(self, name): log.debug("Setting the name to %s" % name) if isinstance(name, str): self.name = name else: raise TypeError()

if __name__ == "__main__": j = JavaStyle() j.set_name("pydanny did this back in 2006!") print(j.get_name())

class PythonStyle(object):

def __init__(self): self._name = ""

@property def name(self): return self._name

@name.setter def name(self, value): """ Because name is probably a string we'll assume that we can infer the type from the variable name""" log.debug("Setting the name to %s" % value) self._name = value

if __name__ == "__main__": p = PythonStyle() p.name = "pydanny doing it the right way" print(p.name)

class WebService(object):

@property def connect(self): self.proxy = xmlrpc.Server("http://service.xml")

if __name__ == '__main__':

ws = WebService() ws.connect

Using property setters as action methods!

A.K.A. Trying to make your Python code look like Ruby

def connect(self): self.proxy = xmlrpc.Server("http://service.xml")

if __name__ == '__main__':

ws = WebService() ws.connect()

Methods please!

@property def connect(self): self.proxy = xmlrpc.Server("http://service.xml")

if __name__ == '__main__':

ws = WebService() ws.connect

def connect(self): self.proxy = xmlrpc.Server("http://service.xml")

if __name__ == '__main__':

ws = WebService() ws.connect()

Exceptions

try: do_akshun(value)except: pass

Passing Generic Exceptions silently

• Ignorance is not bliss

• You have no idea what your system is doing

• Arguably better to not have this in your code

Fixed Python PracticeUse specific exceptions and/or logging

class AkshunDoesNotDo(Exception): """ Custom exceptions makes for maintainable code """ pass

try: do_akshun(value)except AttributeError as e: log.info("Can I get attribution for these slides?") do_bakup_akshun(vlue)except Exception as e: log.debug(str(e)) raise AkshunDoesNotDo(e)

try: do_akshun(value)except: pass

class AkshunDoesNotDo(Exception): """ Custom exceptions makes for maintainable code """ pass

try: do_akshun(value)except AttributeError as e: log.info("Can I get attribution for these slides?") do_bakup_akshun(vlue)except Exception as e: log.debug(str(e)) raise AkshunDoesNotDo(e)

Getting controversial

• Hard to debug

• Security risk

• Sets bad precedents

imports = "from {0} import {1}".format("random", "randrange")exec(imports)print(randrange(10))

Using exec for dynamic imports

• importlib is in the standard library

• Really explicit

• Direct tie into the Python machinery

import importlibfunstuff = importlib.import_module('random')print(funstuff.randrange(10))

Using importlib for dynamic imports

imports = "from {0} import {1}".format("random", "randrange")exec(imports)print(randrange(10))

import importlibfunstuff = importlib.import_module('random')print(funstuff.randrange(10))

• Too many characters on one line

• Lambdas by design does not have docstrings

• Does not necessarily mean less characters

• I can’t get this sample to work!

swap = lambda a, x, y: lambda f = a.__setitem__: (f(x, (a[x], a[y])), f(y, a[x][0]), f(x, a[x][1]))()

Generally using lambdas

• Doc strings that show up nicely in help/Sphinx

• Easier to read

• In Python, functions are first class objects

• Whenever possible avoid using lambdas

def swap(a, x, y): """ Swap two position values in a list """ a[x],a[y] = a[y],a[x]

Side-by-side comparisonWorst Practice Fixed Practiceswap = lambda a, x, y: lambda f = a.__setitem__: (f(x, (a[x], a[y])), f(y, a[x][0]), f(x, a[x][1]))()

def swap(a, x, y): """ Swap two position values in a list """ a[x],a[y] = a[y],a[x]

• You can’t convince me that XML is the better way

• You are forcing me to learn a new language

<pydanny-ml> <do action="call_view">com.pydanny.nextSlide</do> <global name="spam" value="eggs" /></pydanny-ml>

Configuring your project with XML

• Is this the right way?

• This allows conditional logic

• Iterators

• i.e. “Magic Configuration”

spam = "eggs"actions = [ ('call_view', 'com.pydanny.nextSlide')]

Use Python for configuration!

INSTALLED_APPS += [p for p in os.listdir(BASE) if os.path.isdir(p)]MIDDLEWARE_CLASSES = [...]def callback(arg, dirname, fnames): if 'middleware.py' in fnames: m = '%s.middleware' % os.path.split(dirname)[-1] MIDDLEWARE_CLASSES.append(m)

urlpatterns = patterns('', ...)for app in settings.INSTALLED_APPS: if not app.startswith('django'): p = url('^%s/' % app, include('%s.urls') % app) urlpatterns += patterns('', p)

‘Magical configuration code’

http://www.slideshare.net/jacobian/the-best-and-worst-of-django

Fixed Python PracticePREREQ_APPS = [ # Django "django.contrib.admin", "django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.sites", "django.contrib.messages", "django.contrib.humanize", "django.contrib.flatpages",

# external "notification", # must be first "staticfiles", "uni_form", ... ]

urlpatterns = patterns("",

url(r"^$", homepage, name="home"), url(r"âccounts/", include("accounts.urls")), url(r"âdmin/", include(admin.site.urls)), url(r"âbout/", include("about.urls")), url(r"^profiles/", include("profiles.urls")), url(r"^notices/", include("notification.urls")), ... )MIDDLEWARE_CLASSES = [

"django.middleware.common.CommonMiddleware", "django.contrib.sessions.middleware.SessionMiddleware", "django.middleware.csrf.CsrfViewMiddleware", "django.contrib.auth.middleware.AuthenticationMiddleware", "reversion.middleware.RevisionMiddleware", "django.contrib.messages.middleware.MessageMiddleware", ... ]

Explicit is betterthen Implicit

This isn’t that much typing, is it?

Fixed Python PracticePREREQ_APPS = [ # Django "django.contrib.admin", "django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.sites", "django.contrib.messages", "django.contrib.humanize", "django.contrib.flatpages",

# external "notification", # must be first "staticfiles", "uni_form", ... ]

urlpatterns = patterns("",

url(r"^$", homepage, name="home"), url(r"âccounts/", include("accounts.urls")), url(r"âdmin/", include(admin.site.urls)), url(r"âbout/", include("about.urls")), url(r"^profiles/", include("profiles.urls")), url(r"^notices/", include("notification.urls")), ... )MIDDLEWARE_CLASSES = [

"django.middleware.common.CommonMiddleware", "django.contrib.sessions.middleware.SessionMiddleware", "django.middleware.csrf.CsrfViewMiddleware", "django.contrib.auth.middleware.AuthenticationMiddleware", "reversion.middleware.RevisionMiddleware", "django.contrib.messages.middleware.MessageMiddleware", ... ]

Python’s design is predicated on the proposition that code is more often read than written.

http://www.slideshare.net/jacobian/the-best-and-worst-of-django/44

Fixed Python PracticeUse a config file

spam = "eggs"

[actions]call_view = com.pydanny.nextSlide

Read up on config parser

http://docs.python.org/library/configparser.html

XMLlogic heavy python

simple python filesconfig (.cfg) files

Documentation

Python Worst PracticeBad docstrings

• Do really obvious objects require doc strings?

• Complex methods require more than docstrings!

class Pythonista(): # Old style class! """ This class represents a Python programmer """

def code(self): """Write some code """ code, inspiration = Code(), Inspiration() for hour in Effort(): try: code += hour + inspiraion except CurseWorthyBug:

Fixed Python Practiceclass Pythonista(object):

def code(self): """ Writes code following these steps 1. Create a space for coding 2. Get some inspiration 3. Loop through some hours of effort 4. Write some code 5. Pull out hair cause of bugs """ code = Code() inspiration = Inspiration() for hour in Effort(): try: code += hour + inspiraion except CurseWorthyBug: ...

Spend a few minutesdocumenting the critical stuff, okay?

class Pythonista(): # Old style class! """ This class represents a Python programmer """

def code(self): """Write some code """ code, inspiration = Code(), Inspiration() for hour in Effort(): try: code += hour + inspiraion except CurseWorthyBug: ...

class Pythonista(object):

def code(self): """ Writes code following these steps 1. Create a space for coding 2. Get some inspiration 3. Loop through some hours of effort 4. Write some code 5. Pull out hair cause of bugs """ code = Code() inspiration = Inspiration() for hour in Effort(): try: code += hour + inspiraion except CurseWorthyBug: ...

• Generally not version controlled

• Backups? Mirrors?

• Editing via the web? Ugh.

• No pull requests - smaller group of contributors

Using a wiki for project documentation

“Wikis are where project documentation goes to die”Jacob Kaplan-Moss

• Use Restructured Text

• Use Sphinx

• Host on http://readthedocs.org

http://pypi.python.org/pypi/that

>>> import thatThe Anti-Zen of Python, by Daniel Greenfeld

Ugly is better than beautiful.Implicit is better than explicit.Complicated is better than complex.Complex is better than simple.Nested is better than flat.Dense is better than sparse.Line code counts.Special cases are special enough to break the rules.Although purity beats practicality.Errors should always pass silently.Spelchek iz fur loosers.In the face of explicity, succumb to the temptation to guess.There should be many ways to do it.Because only a tiny minority of us are Dutch.Later is the best time to fix something.If the implementation is hard to explain, it's a good sell.If the implementation is easy to explain, it won't take enough time to do.Namespaces are too hard, just use import *!

Fixed Python Practice>>> import thisThe 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!

Core Python

>>> import thatThe Anti-Zen of Python, by Daniel Greenfeld

Ugly is better than beautiful.Implicit is better than explicit.Complicated is better than complex.Complex is better than simple.Nested is better than flat.Dense is better than sparse.Line code counts.Special cases are special enough to break the rules.Although purity beats practicality.Errors should always pass silently.Spelchek iz fur loosers.In the face of explicity, succumb to the temptation to guess.There should be many ways to do it.Because only a tiny minority of us are Dutch.Later is the best time to fix something.If the implementation is hard to explain, it's a good sell.If the implementation is easy to explain, it won't take enough time to do.Namespaces are too hard, just use import *!

>>> import thisThe 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!

Questions?

Python Worst Practices

Technology

Best (and worst) Practices in Customer Communication9bfd06b0373488cec5c7-1ab341a9c7303b5b382cff1181673625.r21.cf2.r… · Best (and worst) Practices in Customer Communication White

4GL Coding Worst Practices

Best & Worst Practices in Measuring Innovation

Grails Worst Practices

Worst Practices in Statistical Data Analysis

OSGi Best and Worst Practices

Sales and Operations Planning Worst Practices

S424. Soa Mainframe Practices Best And Worst

Foursquare best Practices & worst case

SQL Server Worst Practices

Lotusphere 2008 Worst practices

Identifying Worst Information Technology Practices

Avoiding Failed SharePoint Deployments: SharePoint Worst Practices

Facilitation Skills: Best and Worst Facilitator Practices

Iue2011 Worst Practices Published

Ten Worst (and some Best) Demand Forecasting Practices ...cpdftraining.org/downloads/APICS2011_Levenbach_10WorstBest... · Ten Worst (and some Best) Demand Forecasting Practices That

Keith Schengili-Roberts - DITA Worst Practices

When Design Best Practices Become Performance Worst Practices

What were you thinking? Worst Translation Practices

Baltimore SPUG - Worst Practices and Blunders