Python is DOOMED! Again!

Steven D'Aprano steve+comp.lang.python at pearwood.info
Sat Jan 31 22:06:36 EST 2015


Mario Figueiredo wrote:

> In article <54ca5bbf$0$12992$c3e8da3$5496439d at news.astraweb.com>,
> steve+comp.lang.python at pearwood.info says...
>> 
>> Why should I feel guilty? You wrote:
>> 
>> 
>> "Static analysis cannot and should not clutter executable code."
>> 
>> 
>> But what are type declarations in statically typed languages like C,
>> Pascal, Haskell, etc.? They are used by the compiler for static analysis.
>> The same applies to type declarations in dynamically typed languages like
>> Cobra and Julia. And yet, there they are, in the executable code.
>> 
>> So there are a whole lot of languages, going all the way back to 1950s
>> languages like Fortran, to some of the newest languages which are only a
>> few years old like Go, both dynamically typed and statically typed, which
>> do exactly what you say languages "cannot and should not" do: they put
>> type information used for static analysis there in the code.
> 
> You are confusing static analysis with compile time checking which
> produces side-effects like implicit conversion for instance and that
> affects the resulting binary code. Something that Python won't do with
> type annotations. And something that Julia, Scala or C does.

I'm not confusing anything. I'm fully aware of the differences between what
C or Pascal does and what Python does. But I'm also aware of the
similarities.


> This is also the first time I hear compilation time mentioned as static
> analysis.

Compilation consists of many different tasks. They may be explicitly handled
by different tools, or implicitly handled by a single tool. That tool may
combine them into a single phase, or keep them separate. These are all
implementation details: different compilers for the same language could do
this differently.

Typical tasks for a compiler, in no particular order:

- lexing and parsing of source code
- type analysis and checking
- code generation
- linking to external libraries
- optimisation

For languages like C and Pascal, the type checking is typically done
statically at compile-time. So of course they include static analysis. The
compiler hasn't compiled the code yet, so it only has the source code to
work with! A type error will halt the compiler and stop the program from
compiling.


> To be clear, type declarations in Julia, Scala, C have the potential to
> produce side-effects, can result in optimized code and can result in
> compile time errors or warnings. Type annotations in Python are instead
> completely ignored by the interpreter. They do nothing of the above.
> They do not participate in code execution.

As as been pointed out repeatedly, Python annotations DO participate in the
code execution: the annotations are created and stored in the function
object at runtime, and one could easily create a library to use those
annotations at runtime for runtime type-checks.


>> As I said, these languages disagree with you. You are not just arguing
>> against Guido, but against the majority of programming language designers
>> for 60+ years.
> 
> You are right. I'm not arguing against Guido. I have yet to hear his
> opinion on your or mine arguments. I'm not arguing against the majority
> of programming languages either, because they agree with me.

Do you really expect us to believe that the majority of programming
languages put type declarations in docstrings, or a second file separate
from the source of the function? Okay, let's see some examples. Here is a
list of languages still well-known enough that people use them:

http://rosettacode.org/wiki/Category:Programming_Languages


How many of them use docstrings as the only way to declare the type of a
variable? How many use header files as the sole way to declare the type of
variables?

I'm feeling generous. You don't even need to show a *majority* (50%). I'd be
amazed if you can find *ten percent* of those languages that agree with
you.



-- 
Steven




More information about the Python-list mailing list