PEP 8 does not make a recommendation as to which type of quotation mark to use ('single-quotes'
or "double-quotes"
), only that one should be chosen and it should be used consistently throughout the codebase.
Use 'single-quotes'
first and only use "double-quotes"
when it would dramatically complicate the code to properly escape a single-quoted string (applies to docstrings too).
class SomeClass(object):
'''
You do add documentation, right?
'''
def bar(self):
'''
'''
reasonable = 'Isn\'t Python the greatest?'
unreasonable = '\'Please\' \'don\'t\' \'do\' \'this\''
made_reasonable = "'Please' 'don't' 'do' 'this'"
# good!
def foo(bar, baz):
'''
'''
return
# bad!
def foo(bar, baz):
'''asdf'''
Avoid names like to_ret
especially when the variable is long-lived.
The following suggestions reflect the conventions set by the documentation and source code of Django and other third-party packages and
The recommendations in PEP 8 should be taken first. The directory structure encouraged/imposed by Django makes it easy to follow the same ordering of imports across all files. Ignore the import
s and from
s when alphabetizing a group of imports.
__future__
imports: All files must importabsolute_import
andunicode_literals
in preparation for an eventual move to Python 3.- Python Standard Library
- Django
- Third-party packages
- Other apps
- Relative imports
from __future__ import absolute_import, unicode_literals
# python stdlib
from datetime import timedelta
import logging
# django
from django.db import models
from django.utils import timezone
# other third party
from tasty.resources import ModelResource
# apps within the project
from core.models import Company
from schedules.models import Event
# imports relative to the current file
from .models import Invoice
from .utils import partition
# good!
class AwesomeTests(TestCase):
# ....
# bad!
class BadTest(TestCase):
# ...
All Resource
subclasses should exist in a file called resources.py
under the appropriate app directory. In this case, we're simply following the convention set forth by TastyPie to make our code line up more closely with the documentation.
Apps can each have a utils.py
to collect useful functionality used across the modules of the app. Note: we follow the Django convention of using utils.py
not util.py
.
CharField
should never usenull=True