Python is DOOMED! Again!

[Steven D'Aprano]

Mario Figueiredo wrote:

> In article <54c980cd$0$12981$c3e8da3$5496439d at news.astraweb.com>,
> steve+comp.lang.python at pearwood.info says...
>> 
>> Ian, that's obvious. Just open your eyes:
>> 
>> Scala
>> def addInt( a:Int, b:Int ) : Int
>> 
>> Python
>> def addInt( a:int, b:int ) -> int:
>> 
>> 
>> They're COMPLETELY different. In Scala they are *type declarations*, not
>> annotations. We're talking about annotations, not declarations. They're
>> as different as cheese and a very slightly different cheese. Do try to
>> keep up.
>> 
>> *wink*
> 
> The sarcasm is unnecessary. They are different yes. Are you on purpose
> confusing the syntax of a feature with its meaning? Because while you
> have a very similar syntax between Julia, Scala and Python. Their
> meanings are very different.

No they aren't. Their primary meaning is to declare the type used by the
parameter.



> I think it is obvious to anyone that if a feature like type annotations
> are meant to be EVALUATED AT RUNTIME (and I myself gave you another
> example of Julia), it makes every sense for that feature to be a part of
> the programming language syntax. I could never argue against Julia or
> Scala type annotations on that basis. The syntax is an integral part of
> the executable code.

Ah, you mean just like Python, where annotations are evaluated at runtime,
just like Julia:

py> def spam(n:int)-> getattr(sys, 'version'):
...     return "spam"*n
...
py> spam.__annotations__
{'n': <class 'int'>, 'return': '3.3.0rc3 (default, Sep 27 2012, 18:44:58)
\n[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)]'}


Python has had annotations for over five years. They are evaluated at
runtime. They will continue to be evaluated at runtime.

One of the benefits of this system is that people may write *runtime*
type-checkers that use the same annotations that the lexical analysis tools
will use.

It is possible that you aren't following the meaning of this. The idea
behind PEP 484 is that Python will standardise on a single expected syntax
for type-hints, so that all of the following tools can agree on a set of
basic rules for interpreting the annotations:

- lexical type-checkers (those that operate on only the source code, 
  with no runtime information)
- alternate Python compilers, like MyPy, which perform compile-time 
  type checking
- IDEs and text editors, which may use lexical type info available
  in the source code to flag errors and offer auto-completion
- stand-alone tools such as correctness provers
- documentation generators
- runtime type-checkers
- runtime introspection tools

and more.

One of the rules is that the *standard* type-hints have to be simple enough
that a purely lexical tool like an IDE or editor can understand it without
needing to run arbitrary code. But the annotations themselves can be
arbitrarily complex Python expressions. Its just that then the tools
expecting type-hints won't be able to process those annotations from the
source code alone. Runtime introspection tools will not care, because they
don't see the expression, they only see the result of evaluating that
expression.


> But when a feature is not meant for runtime evaluation, why should it
> clutter your executable code? Make me understand your reasoning?

Perhaps you should ask the designers of Pascal, Go, Scheme, C, D, F# and all
those dozens and hundreds of other languages. They have a feature which is
not evaluated at runtime -- the type declarations -- and they put it in the
source code.

And why shouldn't they? Type declarations are source code!


> Your list of programming languages is just plain wrong. To my knowledge
> (there's a few languages there I don't know and never used), none of
> those languages implement anything like Python. 

Not so.


> Type annotations in 
> python are entirely ignored by the interpreter except to make them 
> available to external libraries. 


That is incorrect.

Perhaps you are confusing by the fact that the Python interpreter doesn't
give any meaning to annotations? It still evaluates them at runtime, and
stores the result in the function object.



-- 
Steven