realpython · kennethreitz · Jul 31, 2013 · Jul 30, 2013 · Jul 30, 2013 · Jul 30, 2013
diff --git a/docs/dev/env.rst b/docs/dev/env.rst
@@ -16,8 +16,8 @@ Vim is a text editor which uses keyboard shortcuts for editing instead of menus
 or icons. There exist a couple of plugins and settings for the VIM editor to
 aid Python development. If you only develop in Python, a good start is to set
 the default settings for indentation and line-wrapping to values compliant with
-`PEP 8 <http://www.python.org/dev/peps/pep-0008/>`_. In your home directory,
-open a file called `.vimrc` and add the following lines:::
+:pep:`8`. In your home directory, open a file called `.vimrc` and add the
+following lines:::
 
     set textwidth=79  " lines longer than 79 columns will be broken
     set shiftwidth=4  " operation >> indents 4 columns; << unindents 4 columns
@@ -113,12 +113,14 @@ scripters and novice users alike."
 Sublime Text
 ------------
 
-"`Sublime Text <http://www.sublimetext.com/>`_ is a sophisticated text editor
-for code, html and prose. You'll love the slick user interface and
-extraordinary features."
+    `Sublime Text <http://www.sublimetext.com/>`_ is a sophisticated text
+    editor for code, markup and prose. You'll love the slick user interface,
+    extraordinary features and amazing performance.
 
 Sublime Text has excellent support for editing Python code and uses Python for
-its plugin API.
+its plugin API. It also has plugins a diverse variety of plugins, `some of which <https://github.com/SublimeLinter/SublimeLinter>`_
+allow for in-editor PEP8 checking and code "linting".
+
 
 IDEs
 ::::

diff --git a/docs/intro/community.rst b/docs/intro/community.rst
@@ -27,7 +27,7 @@ PEPs
 PEPs are *Python Enhancement Proposals*. They describe changes to Python itself,
 or the standards around it.
 
-There are three different types of PEPs (as defined by `PEP1 <http://www.python.org/dev/peps/pep-0001/>`_):
+There are three different types of PEPs (as defined by :pep:`1`):
 
     **Standards**
         Describes a new feature or implementation.
@@ -45,13 +45,13 @@ Notable PEPs
 
 There are a few PEPs that could be considered required reading:
 
-- `PEP8 <http://www.python.org/dev/peps/pep-0008/>`_: The Python Style Guide.
+- :pep:`8`: The Python Style Guide.
     Read this. All of it. Follow it.
 
-- `PEP20 <http://www.python.org/dev/peps/pep-0020/>`_: The Zen of Python.
+- :pep:`20`: The Zen of Python.
     A list of 19 statements that briefly explain the philosophy behind Python.
 
-- `PEP257 <http://www.python.org/dev/peps/pep-0257/>`_: Docstring Conventions.
+- :pep:`257`: Docstring Conventions.
     Gives guidelines for semantics and conventions associated with Python
     docstrings.
 

diff --git a/docs/intro/duction.rst b/docs/intro/duction.rst
@@ -82,7 +82,6 @@ whether they're an old hand or a first-time Pythonista, and the authors to
 the Guide will gladly help if you have any questions about the
 appropriateness, completeness, or accuracy of a contribution.
 
-To get started working on The Hitchhiker's Guide, see
-the: doc:`/notes/contribute` page.
+To get started working on The Hitchhiker's Guide, see the :doc:`/notes/contribute` page.
 
 
diff --git a/docs/intro/learning.rst b/docs/intro/learning.rst
@@ -65,7 +65,7 @@ Python Koans
 
 Python Koans is a port of Edgecase's Ruby Koans.  It uses a test-driven
 approach, q.v. TEST DRIVEN DESIGN SECTION to provide an interactive tutorial
-teaching basic python concepts.  By fixing assertion statements that fail in a 
+teaching basic python concepts.  By fixing assertion statements that fail in a
 test script, this provides sequential steps to learning python.
 
 For those used to languages and figuring out puzzles on their own, this can be
@@ -105,7 +105,7 @@ is focused on the more advanced crowd.
 
 It starts with topics like decorators (with caching, proxy, and context manager
 case-studies), method resolution order, using super() and meta-programming, and
-general PEP8 best practices.
+general :pep:`8` best practices.
 
 It has a detailed, multi-chapter case study on writing and releasing a package
 and eventually an application, including a chapter on using zc.buildout.  Later

diff --git a/docs/notes/license.rst b/docs/notes/license.rst
@@ -1,4 +1,5 @@
+=======
 License
--------
+=======
 
-.. todo:: Determine License
+The Guide is licensed under the `Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license <https://creativecommons.org/licenses/by-nc-sa/3.0/>`_.
diff --git a/docs/notes/styleguide.rst b/docs/notes/styleguide.rst
@@ -39,24 +39,32 @@ Headings
 
 Use the following styles for headings.
 
-Chapter title::
+Chapter title:
+
+.. code-block:: rest
 
     #########
     Chapter 1
     #########
 
-Page title::
+Page title:
+
+.. code-block:: rest
 
     ===================
     Time is an Illusion
     ===================
 
-Section headings::
+Section headings:
+
+.. code-block:: rest
 
     Lunchtime Doubly So
     -------------------
 
-Sub section headings::
+Sub section headings:
+
+.. code-block:: rest
 
     Very Deep
     ~~~~~~~~~
@@ -74,7 +82,9 @@ Code Examples
 
 Wrap all code examples at 70 characters to avoid horizontal scrollbars.
 
-Command line examples::
+Command line examples:
+
+.. code-block:: rest
 
     .. code-block:: console
 
@@ -83,15 +93,19 @@ Command line examples::
 
 Be sure to include the ``$`` prefix before each line.
 
-Python interpreter examples::
+Python interpreter examples:
+
+.. code-block:: rest
 
     Label the example::
 
     .. code-block:: python
 
         >>> import this
 
-Python examples::
+Python examples:
+
+.. code-block:: rest
 
     Descriptive title::
 
@@ -103,16 +117,20 @@ Python examples::
 Externally Linking
 ------------------
 
-* Prefer labels for well known subjects (ex: proper nouns) when linking::
+* Prefer labels for well known subjects (ex: proper nouns) when linking:
+
+  .. code-block:: rest
 
-    Sphinx_ is used to document Python.
+      Sphinx_ is used to document Python.
 
-    .. _Sphinx: http://sphinx.pocoo.org
+      .. _Sphinx: http://sphinx.pocoo.org
 
 * Prefer to use descriptive labels with inline links instead of leaving bare
-  links::
+  links:
+
+  .. code-block:: rest
 
-    Read the `Sphinx Tutorial <http://sphinx.pocoo.org/tutorial.html>`_
+      Read the `Sphinx Tutorial <http://sphinx.pocoo.org/tutorial.html>`_
 
 * Avoid using labels such as "click here", "this", etc. preferring
   descriptive labels (SEO worthy) instead.
@@ -124,7 +142,9 @@ To cross-reference other parts of this documentation, use the `:ref:
 <http://sphinx.pocoo.org/markup/inline.html#cross-referencing-arbitrary-locations>`_
 keyword and labels.
 
-To make reference labels more clear and unique, always add a ``-ref`` suffix::
+To make reference labels more clear and unique, always add a ``-ref`` suffix:
+
+.. code-block:: rest
 
     .. _some-section-ref:
 
@@ -137,14 +157,18 @@ Notes and Warnings
 Make use of the appropriate `admonitions directives
 <http://sphinx.pocoo.org/rest.html#directives>`_ when making notes.
 
-Notes::
+Notes:
+
+.. code-block:: rest
 
     .. note::
         The Hitchhiker’s Guide to the Galaxy has a few things to say
         on the subject of towels. A towel, it says, is about the most
         massively useful thing an interstellar hitch hiker can have.
 
-Warnings::
+Warnings:
+
+.. code-block:: rest
 
     .. warning:: DON'T PANIC
 
@@ -156,7 +180,7 @@ Please mark any incomplete areas of The Guide with a `todo directive
 avoid cluttering the :ref:`todo-list-ref`, use a single ``todo`` for stub
 documents or large incomplete sections.
 
-::
+.. code-block:: rest
 
     .. todo::
         Learn the Ultimate Answer to the Ultimate Question

diff --git a/docs/scenarios/db.rst b/docs/scenarios/db.rst
@@ -5,7 +5,7 @@ DB-API
 ------
 
 The Python Database API (DB-API) defines a standard interface for Python
-database access modules. It's documented in `PEP 249 <http://www.python.org/dev/peps/pep-0249/>`_.
+database access modules. It's documented in :pep:`249`.
 Nearly all Python database modules such as `sqlite3`, `psycopg` and
 `mysql-python` conform to this interface.
 

diff --git a/docs/scenarios/imaging.rst b/docs/scenarios/imaging.rst
@@ -12,7 +12,7 @@ The `Python Imaging Library <http://www.pythonware.com/products/pil/>`_, or PIL
 for short, is *the* library for image manipulation in Python. Unfortunately, its
 development has stagnated, with its last release in 2009.
 
-Lucky for you, there's an actively-developed fork of PIL called `Pillow <http://python-imaging.github.io/>`_ -
+Luckily for you, there's an actively-developed fork of PIL called `Pillow <http://python-imaging.github.io/>`_ -
 it's easier to install, runs on all operating systems, and supports Python 3.
 
 Installation

diff --git a/docs/scenarios/web.rst b/docs/scenarios/web.rst
@@ -18,7 +18,7 @@ interface between web servers and Python web application frameworks. By
 standardizing behavior and communication between web servers and Python web
 frameworks, WSGI makes it possible to write portable Python web code that
 can be deployed in any :ref:`WSGI-compliant web server <wsgi-servers-ref>`.
-WSGI is documented in `PEP-3333 <http://www.python.org/dev/peps/pep-3333/>`_.
+WSGI is documented in :pep:`3333`.
 
 
 Frameworks

diff --git a/docs/writing/documentation.rst b/docs/writing/documentation.rst
@@ -104,9 +104,7 @@ In Python, *docstrings* describe modules, classes, and functions: ::
         """Returns the square root of self times self."""
         ...
 
-In general, follow the `comment section of PEP 0008`_ (the "Python Style Guide").
-
-.. _comment section of PEP 0008: http://www.python.org/dev/peps/pep-0008/#comments
+In general, follow the comment section of :pep:`8#comments` (the "Python Style Guide").
 
 Commenting Sections of Code
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -137,9 +135,7 @@ operation of the function or class: ::
         """Returns the square root of self times self."""
 	...
 
-.. seealso:: Further reading on docstrings: `PEP 0257`_
-
-.. _PEP 0257: http://www.python.org/dev/peps/pep-0257/
+.. seealso:: Further reading on docstrings: :pep:`257`
 
 
 Other Tools

diff --git a/docs/writing/structure.rst b/docs/writing/structure.rst
@@ -35,9 +35,9 @@ include:
 
 - Multiple and messy circular dependencies: if your classes
   Table and Chair in furn.py need to import Carpenter from workers.py
-  to answer a question such as table.isdoneby(),
+  to answer a question such as ``table.isdoneby()``,
   and if conversely the class Carpenter needs to import Table and Chair,
-  to answer the question carpenter.whatdo(), then you
+  to answer the question ``carpenter.whatdo()``, then you
   have a circular dependency. In this case you will have to resort to
   fragile hacks such as using import statements inside
   methods or functions.
@@ -236,7 +236,7 @@ processes are spawned to respond to external requests that can
 happen at the same time. In this case, holding some state into instantiated
 objects, which means keeping some static information about the world, is prone
 to concurrency problems or race-conditions. Sometimes, between the initialization of
-the state of an object (usually done with the __init__() method) and the actual use
+the state of an object (usually done with the ``__init__()`` method) and the actual use
 of the object state through one of its methods, the world may have changed, and
 the retained state may be outdated. For example, a request may load an item in
 memory and mark it as read by a user. If another request requires the deletion
@@ -383,7 +383,7 @@ Python has two kinds of built-in or user-defined types.
 
 Mutable types are those that allow in-place modification
 of the content. Typical mutables are lists and dictionaries:
-All lists have mutating methods, like append() or pop(), and
+All lists have mutating methods, like ``append()`` or ``pop()``, and
 can be modified in place. The same goes for dictionaries.
 
 Immutable types provide no method for changing their content.
@@ -418,7 +418,7 @@ its parts, it is much more efficient to accumulate the parts in a list,
 which is mutable, and then glue ('join') the parts together when the
 full string is needed. One thing to notice, however, is that list
 comprehensions are better and faster than constructing a list in a loop
-with calls to append().
+with calls to ``append()``.
 
 **Bad**
 
@@ -448,10 +448,10 @@ with calls to append().
     nums = [str(n) for n in range(20)]
     print "".join(nums)
 
-One final thing to mention about strings is that using join() is not always
+One final thing to mention about strings is that using ``join()`` is not always
 best. In the instances where you are creating a new string from a pre-determined
 number of strings, using the addition operator is actually faster, but in cases
-like above or in cases where you are adding to an existing string, using join()
+like above or in cases where you are adding to an existing string, using ``join()``
 should be your preferred method.
 
 .. code-block:: python
@@ -464,11 +464,10 @@ should be your preferred method.
     foo = ''.join([foo, 'ooo'])
 
 .. note::
-    You can also use the **%** formatting operator to concatenate the
-    pre-determined number of strings besides **join()** and **+**. However,
-    according to `PEP 3101 <http://www.python.org/dev/peps/pep-3101/>`_,
-    **%** operator became deprecated in Python 3.1 and will be replaced by the
-    **format()** method in the later versions.
+    You can also use the ``%`` formatting operator to concatenate the
+    pre-determined number of strings besides ``join()`` and ``+``. However,
+    according to :pep:`3101`, the ``%`` operator became deprecated in
+    Python 3.1 and will be replaced by the ``format()`` method in the later versions.
 
 .. code-block:: python
 

diff --git a/docs/writing/style.rst b/docs/writing/style.rst
@@ -117,8 +117,8 @@ follow the syntax that is the closest to the function definition: ``send('Hello'
 'World', cc='Cthulhu', bcc='God')``.
 
 As a side note, following `YAGNI <http://en.wikipedia.org/wiki/You_ain't_gonna_need_it>`_
-principle, it is often harder to remove an optional argument (and its logic inside the 
-function) that was added "just in case" and is seemingly never used, than to add a 
+principle, it is often harder to remove an optional argument (and its logic inside the
+function) that was added "just in case" and is seemingly never used, than to add a
 new optional argument and its logic when needed.
 
 3. The **arbitrary argument list** is the third way to pass arguments to a
@@ -256,14 +256,14 @@ are a probable indication that such a refactoring is needed.
 Idioms
 ------
 
-A programming idiom, put simply, is a *way* to write code. The notion of programming idioms 
+A programming idiom, put simply, is a *way* to write code. The notion of programming idioms
 is discussed amply at `c2 <http://c2.com/cgi/wiki?ProgrammingIdiom>`_ and at `Stack Overflow <http://stackoverflow.com/questions/302459/what-is-a-programming-idiom>`_.
 
-Idiomatic Python code is often referred to as being *Pythonic*. 
+Idiomatic Python code is often referred to as being *Pythonic*.
 
-Although there usually is one-- and preferably only one --obvious way to do it; 
+Although there usually is one-- and preferably only one --obvious way to do it;
 *the* way to write idiomatic Python code can be non-obvious to Python beginners. So,
-good idioms must be consciously acquired. 
+good idioms must be consciously acquired.
 
 Some common Python idioms follow:
 
@@ -362,7 +362,7 @@ For more information see this `StackOverflow <http://stackoverflow.com/questions
 Zen of Python
 -------------
 
-Also known as PEP 20, the guiding principles for Python's design.
+Also known as :pep:`20`, the guiding principles for Python's design.
 
 ::
 
@@ -397,9 +397,7 @@ slides from a Python user group
 PEP 8
 -----
 
-PEP 8 is the de-facto code style guide for Python.
-
-    `PEP 8 <http://www.python.org/dev/peps/pep-0008/>`_
+:pep:`8` is the de-facto code style guide for Python.
 
 Conforming your Python code to PEP 8 is generally a good idea and helps make
 code more consistent when working on projects with other developers. There