diff --git a/pep-0008.txt b/pep-0008.txt
index ca9cf7d..87194ae 100644
--- a/pep-0008.txt
+++ b/pep-0008.txt
@@ -245,19 +245,23 @@ thoughts on the indentation of such multiline ``with``-statements.)
 Another such case is with ``assert`` statements.
 
 Make sure to indent the continued line appropriately.  The preferred
-place to break around a binary operator is *after* the operator, not
-before it.  Some examples::
+place to break around a binary operator is *before* the operator, not
+after it, as suggested by Donald Knuth in his writings about typesetting [3]_.
+Some examples::
 
     class Rectangle(Blob):
 
         def __init__(self, width, height,
                      color='black', emphasis=None, highlight=0):
-            if (width == 0 and height == 0 and
-                    color == 'red' and emphasis == 'strong' or
-                    highlight > 100):
+            if (width == 0
+                and height == 0
+                and color == 'red'
+                and emphasis == 'strong'
+                or highlight > 100
+            ):
                 raise ValueError("sorry, you lose")
-            if width == 0 and height == 0 and (color == 'red' or
-                                               emphasis is None):
+            if width == 0 and height == 0 and (color == 'red'
+                                               or emphasis is None):
                 raise ValueError("I don't think so -- values are %s, %s" %
                                  (width, height))
             Blob.__init__(self, width, height,
@@ -709,7 +713,7 @@ The following naming styles are commonly distinguished:
 - ``UPPERCASE``
 - ``UPPER_CASE_WITH_UNDERSCORES``
 - ``CapitalizedWords`` (or CapWords, or CamelCase -- so named because
-  of the bumpy look of its letters [3]_).  This is also sometimes known
+  of the bumpy look of its letters [4]_).  This is also sometimes known
   as StudlyCaps.
 
   Note: When using abbreviations in CapWords, capitalize all the
@@ -1286,7 +1290,7 @@ annotations are changing.
   PEP 484 recommends the use of stub files: .pyi files that are read
   by the type checker in preference of the corresponding .py files.
   Stub files can be distributed with a library, or separately (with
-  the library author's permission) through the typeshed repo [4]_.
+  the library author's permission) through the typeshed repo [5]_.
 
 - For code that needs to be backwards compatible, function annotations
   can be added in the form of comments.  Basically, this Python 3 annotation::
@@ -1302,7 +1306,7 @@ annotations are changing.
         """Embezzle funds from account using fake receipts."""
         <code goes here>
 
-  The mypy type checker [5]_ currently supports this syntax, and other
+  The mypy type checker [6]_ currently supports this syntax, and other
   type checkers are encouraged to adopt it.
 
 
@@ -1324,12 +1328,14 @@ References
 .. [2] Barry's GNU Mailman style guide
        http://barry.warsaw.us/software/STYLEGUIDE.txt
 
-.. [3] http://www.wikipedia.com/wiki/CamelCase
+.. [3] http://rhodesmill.org/brandon/slides/2012-11-pyconca/#laying-down-the-law
 
-.. [4] Typeshed repo
+.. [4] http://www.wikipedia.com/wiki/CamelCase
+
+.. [5] Typeshed repo
    https://github.com/python/typeshed
 
-.. [5] mypy type checker
+.. [6] mypy type checker
    http://mypy-lang.org
    https://github.com/JukkaL/mypy