Mario Figueiredo wrote: > In article <54ca5bbf$0$12992$c3e8da3$54964...@news.astraweb.com>, > steve+comp.lang.pyt...@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 -- https://mail.python.org/mailman/listinfo/python-list