Minor additions to PEP 526 following discussions on python-dev (#96)

pep-0526.txt

@@ -110,8 +110,10 @@ will have to be developed to implement such functionality.
 
 It should also be emphasized that **Python will remain a dynamically typed
 language, and the authors have no desire to ever make type hints mandatory,
-even by convention.** The goal of annotation syntax is to provide an
-easy way to specify structured type metadata for third party tools.
+even by convention.** Type annotations should not be confused with variable
+declarations in statically typed languages. The goal of annotation syntax is
+to provide an easy way to specify structured type metadata
+for third party tools.
 
 This PEP does not require type checkers to change their type checking
 rules. It merely provides a more readable syntax to replace type
@@ -130,6 +132,13 @@ party type checker::
   other_var: int  = 'a'  # Flagged as error by type checker,
                          # but OK at runtime.
 
+This syntax does not introduce any new semantics beyond PEP 484, so that
+the following three statements are equivalent::
+
+  var = value # type: annotation
+  var: annotation; var = value
+  var: annotation = value
+
 Below we specify the syntax of type annotations
 in different contexts and their runtime effects.
 
@@ -474,6 +483,13 @@ Rejected/Postponed Proposals
   define variables does not increase clarity.  (Though this is of
   course subjective.)
 
+- **Use function based syntax**:
+  It was proposed to annotate types of variables using
+  ``var = cast(annotation[, value])``. Although this syntax
+  alleviates some problems with type comments like absence of tne annotation
+  in AST, it does not solve other problems such as readability
+  and it introduces possible runtime overhead.
+
 - **Allow type annotations for tuple unpacking:**
   This causes ambiguity: it's not clear what this statement means::
 
@@ -528,10 +544,10 @@ Rejected/Postponed Proposals
 - **Allow instance variable annotations only in methods:**
   The problem is that many ``__init__`` methods do a lot of things besides
   initializing instance variables, and it would be harder (for a human)
-  to find all the instance variable declarations.
+  to find all the instance variable annotations.
   And sometimes ``__init__`` is factored into more helper methods
   so it's even harder to chase them down. Putting the instance variable
-  declarations together in the class makes it easier to find them,
+  annotations together in the class makes it easier to find them,
   and helps a first-time reader of the code.
 
 - **Use syntax** ``x: class t = v`` **for class variables:**
@@ -554,7 +570,7 @@ Rejected/Postponed Proposals
   are always evaluated. Although this might be reconsidered in future,
   it was decided in PEP 484 that this would have to be a separate PEP.
 
-- **Declare variable types in class docstring:**
+- **Annotate variable types in class docstring:**
   Many projects already use various docstring conventions, often without
   much consistency and generally without conforming to the PEP 484 annotation
   syntax yet. Also this would require a special sophisticated parser.