diff -r 5b67d0028fc7 pep-0484.txt
--- a/pep-0484.txt	Sun May 08 13:46:14 2016 -0700
+++ b/pep-0484.txt	Sun May 08 18:26:02 2016 -0700
@@ -725,8 +725,11 @@
 Forward references
 ------------------
 
-When a type hint contains names that have not been defined yet, that
-definition may be expressed as a string literal, to be resolved later.
+Unlike type hints in comments and stub files, hints in function
+annotations are evaluated at runtime. A type hint in a function
+annotation should be expressed as a string literal if it contains
+names that have not been defined yet. The type checker is responsible
+for resolving these string literals to the types they represent.
 
 A situation where this occurs commonly is the definition of a
 container class, where the class being defined occurs in the signature
@@ -1662,14 +1665,16 @@
 "forward" references there is no problem in ensuring that a name is
 defined before the function using it is called.
 
-The problem with type hints is that annotations (per PEP 3107, and
-similar to default values) are evaluated at the time a function is
-defined, and thus any names used in an annotation must be already
-defined when the function is being defined.  A common scenario is a
-class definition whose methods need to reference the class itself in
-their annotations.  (More general, it can also occur with mutually
-recursive classes.)  This is natural for container types, for
-example::
+This is not an issue for type hints that are not evaluated at runtime,
+such as those in comments or stub files. In those cases, the type
+checker is expected to resolve unquoted forward references. However,
+function annotations (per PEP 3107, and similar to default values) are
+evaluated at the time a function is defined, and thus any names used
+in an annotation must be already defined when the function is being
+defined.  A common scenario is a class definition whose methods need
+to reference the class itself in their annotations. (More general, it
+can also occur with mutually recursive classes.) This is natural for
+container types, for example::
 
   class Node:
       """Binary tree node."""