Python is DOOMED! Again!

[Ian Kelly]

On Thu, Jan 29, 2015 at 1:34 AM, Mario Figueiredo <marfig at gmail.com> 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.
>
> 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.

Okay, I don't know enough about Scala's type system to discuss that
example in this context, so I won't try to. Let's instead focus on
another of the languages you listed: C. C includes types in its
syntax, which it uses for static analysis at compile time. At runtime,
it uses them for ... nothing. In fact, if you examine a compiled C
binary, you won't even find any type information in there. If you
dynamically load a C library containing a function that takes a
double, and you pass it a long, it won't even blink. It will just
assume that the data it received represents a double and proceed from
there.

Now with PEP 484 type annotations on the other hand, while the
suggested static analysis tools aren't used at runtime, the
annotations themselves are available to be evaluated at runtime. If
you want to write a decorator that examines the types of the arguments
of the function it decorates and does something nifty with them
(automatic registration of overloaded functions using PEP 443
generics, perhaps), there is absolutely nothing stopping you from
doing that.