Merge pull request #1 from JimJJewett/JimJJewett-patch-1

Clarify pep-0484 as opt-in conventions only like WSGI

Author: JimJJewett

pep-0484.txt

@@ -16,10 +16,22 @@ Resolution:
 Abstract
 ========
 
-This PEP introduces a standard syntax for type hints using annotations
-(PEP 3107) on function definitions.  For example, here is a simple
-function whose argument and return type are declared in the
-annotations::
+PEP 3107 introduced syntax for function annotations, but the semantics
+were deliberately left undefined.  There has now been enough 3rd party
+usage for static type analysis that the community would benefit from 
+a standard vocabulary and baseline tools within the standard library.
+
+This PEP introduces a provisional module to provide these standard
+definitions and tools, along with some conventions for situations
+where annotations are not available.  
+
+Note that this PEP still explicitly does NOT prevent other uses of 
+annotations, nor does it require (or forbid) any particular processing 
+of annotations, even when they conform to this specification.  It
+simply enables better coordination, as PEP 333 did for web frameworks.
+
+For example, here is a simple function whose argument and return type 
+are declared in the annotations::
 
   def greeting(name: str) -> str:
       return 'Hello ' + name
@@ -29,6 +41,9 @@ While these annotations are available at runtime through the usual
 Instead, the proposal assumes the existence of a separate off-line
 type checker which users can run over their source code voluntarily.
 Essentially, such a type checker acts as a very powerful linter.
+(While it would of course be possible for individual users to employ
+a similar checker at run time for Design By Contract enforcement or 
+JIT optimization, those tools are not yet as mature.)
 
 The proposal is strongly inspired by mypy [mypy]_.  For example, the
 type "sequence of integers" can be written as ``Sequence[int]``.  The