[Python-ideas] Optional static typing -- the crossroads

[Terry Reedy]

On 8/15/2014 12:40 AM, Nick Coghlan wrote:
> On 15 August 2014 09:56, Guido van Rossum <guido at python.org> wrote:
>>
>> I don't buy the argument that PEP 3107 promises that annotations are
>> completely free of inherent semantics.
>
> It's also worth noting the corresponding bullet point in PEP 3100
> (under http://www.python.org/dev/peps/pep-3100/#core-language):
>
> * Add optional declarations for static typing [45] [10] [done]
...
> Linters/checkers may also want to provide a configurable way to say
> "the presence of decorator <X> means the annotations on that function
> aren't type markers". That ties in with the recommendation we added to
> PEP 8 a while back: "It is recommended that third party experiments
> with annotations use an associated decorator to indicate how the
> annotation should be interpreted."

Depending on the checker, this suggests that non-type-check annotations 
need not be deprecated. If a decorator wraps a function with an 
unannotated wrapper, then the checker should see the result as 
unannotated, rather than looking for a wrapped attribute. Also, a 
decorator can remove non-type annotations and act on them, store them in 
a closure variable, or store them on the function in a different name. 
For example.

 >>> def doodad(f):
	f.doodad = f.__annotations__
	f.__annotations__ = {}
	return f

 >>> @doodad
def f(x:'arg doodad')->'return:doodad':
     pass

 >>> f.__annotations__
{}
 >>> f.doodad
{'x': 'arg doodad', 'return': 'return:doodad'}

Given these possibilities, all that is needs be said is "After a 
function is post-processed by decorators, any remaining annotations 
should be for type-checking or documentation."

For checkers that do look at the source, or the AST before compiling, 
the rule could be to ignore string annotations. Decorators can always 
eval, or perhaps safe_eval, strings.

-- 
Terry Jan Reedy