4 ms·

No it isn't. In a static type system, you're not relying on annotations because the types are all known statically. But in a dynamic type system, you can have r

No it isn't. In a static type system, you're not relying on annotations because the types are all known statically. But in a dynamic type system, you can have regions of untyped code where the best your third party static analyzer can do is slap "Any" on them and you watch as the precision of your type checking erodes to nothing.

joshuamorton 6y ago
What is `public static void main(string args)` but an "annotation"? You can stick "untyped" code in any language. You just have to annotate things with `Object` and cast them.
- sdht0 6y ago
  A more appropriate example is: `var list = new ArrayList<String>();` [1] The compiler figures out the type of `list` without "annotations". Same with C++'s `auto` and Rust's `let`. [1] https://openjdk.java.net/jeps/286 https://openjdk.java.net/jeps/286
  - joshuamorton 6y ago
    To clarify, no, this is a complete non-sequitor. The ability for a type system to do inference has no bearing on whether or not the types are checked or not. To make things even more confusing, as an example, python can have type inference (pytype) or not (mypy). In either case, annotations are type checked.
    - sdht0 6y ago
      The other discussions have already pointed out some limitations in your interpretation (heh) of types. I think the key difference between the annotations in Python and types in Java, or even more strongly in languages like Rust and Haskell, is how they are used in the language ecosystem. In Java and Rust, the types are cental to how programmers think in those languages. A large part of the dev cycle goes into ensuring the types are consistent. In python, these type annotations are a relatively recent addition that the community has not completely adopted yet. A lot of real-world python code will have no types, thus the (3rd party) python type checkers will fail to ensure the benefits of having strong consistent types. And how can we then justify "types" like Object in Java or Any in Rust? Well, sometimes we do want to write code where we want to tell the compiler to stop checking types. However, these are more of an escape hatch rather than a central part of the language ecosystem. As someone else already pointed out, the Java or Rust community does not go about writing code with only Object or Any, even though they can in principle. But in python, that's what the community has been doing till now. It goes the other way too. If the python community starts taking the type annotations seriously, it will start approaching the same usefulness as in these other static languages with good type systems. Then we can start expecting that the 3rd party library type annotations being accurate, which started this discussion in the first place.
      - joshuamorton 6y ago
        > In python, these type annotations are a relatively recent addition that the community has not completely adopted yet. I think you'll find I've said as much elsewhere ;) I think I make essentially the same argument as you do here: https://news.ycombinator.com/item?id=24701113 https://news.ycombinator.com/item?id=24701113
        sdht0 6y ago
        Yeah sorry, I stopped reading after I felt the discussion was going round in circles. But it's funny how the same viewpoint results in different takeaways. Of course, the topic under discussion is a pedantic one. However, "that's true of any type system" just feels dismissive of the current state of the world. The comment you were replying to was pointing out that at present, enabling strict type checking in Python, that has been bolted on as an add-on only recently, will not be able to provide benefits to the same level as the ones in Java and Rust where types are front and center. That might become true tomorrow when all Python libraries have adopted types. Hypothetically, tomorrow the Rust community could also decide to adopt Any as the central type everyone uses. But today, the state of the world is very different. Python is still known as a dynamically typed language where devs can essentially forget explicit types, and Rust is a strongly statically typed language where devs will rarely have to worry about missing types.
- DonaldPShimoda 6y ago
  An annotation is when you write some information and it doesn't directly impact the evaluation of that which it annotates. It's a "note", essentially. Type annotations in Python do not actually affect any aspect of runtime and are ignored during evaluation. This is why you need a third-party tool to look at them. You can actually stick any arbitrary code you like after that colon — it's all ignored just the same. What you're referring to are called type ascriptions, and they are often seen in what are sometimes called manifest type systems, where you must explicitly write out your types within a static type system. C and Java are common examples of this. These are not annotations because they have real meaning (either used for declaration or for type conversion). Additionally, there are plenty of statically typed languages which do not require ascription. These languages feature type inference, which is a process that allows the programmer to leave the deduction of the actual types to the compiler. Haskell, Swift, OCaml, Scala, and I think now C++ to some degree (with `auto`) allow for this (to name but a few).
  - joshuamorton 6y ago
    > Type annotations in Python do not actually affect any aspect of runtime and are ignored during evaluation. This is equally true in Java. Types are erased at runtime. They don't exist in the bytecode. Just because the type checking and evaluation are done using one tool, "javac" doesn't really mean anything. Again, what's the difference between a bash script that runs mypy prior to invoking python and a bash script that compiles and runs a java program, from the perspective of type safety, assuming you know nothing about the two programs? There is no difference. Neither provides any more guarantees than the other. Put another way, by enforcing use of mypy prior to invocation, you convert the annotation to an ascription. A deeper analysis would suggest that "ascriptions" are actually the things you use to disambiguate when type inference is not powerful enough (https://docs.scala-lang.org/style/types.html https://docs.scala-lang.org/style/types.html). Scala, for example, calls its type declarations "annotations", except when they are needed to disambiguate, when they are "ascriptions". So under the scala definition, python's annotations are exactly the same as scalas as long as they are used for type checking, which, if you use mypy, they are.
    - 6y ago
kobalsky 6y ago
I don't know if mypy allows you to mock the API but at least flow does for javascript. If a library is untyped you get a file with all the exported functions and you can quickly set the types for the functions that you interface with. We have been using this for a couple of years and it's a godsend. There's a community project to share these external library definitions https://github.com/flow-typed/flow-typed https://github.com/flow-typed/flow-typed
- DonaldPShimoda 6y ago
  That's a neat feature!
  - icebraining 6y ago
    You can do the same in mypy by generating a stub file: https://mypy.readthedocs.io/en/stable/stubs.html https://mypy.readthedocs.io/en/stable/stubs.html
    - DonaldPShimoda 6y ago
      ! I had no idea. Super cool — thanks for letting me know!

joshuamorton 6y ago

What is `public static void main(string args)` but an "annotation"? You can stick "untyped" code in any language. You just have to annotate things with `Object` and cast them.

sdht0 6y ago
A more appropriate example is: `var list = new ArrayList<String>();` [1] The compiler figures out the type of `list` without "annotations". Same with C++'s `auto` and Rust's `let`. [1] https://openjdk.java.net/jeps/286 https://openjdk.java.net/jeps/286
- joshuamorton 6y ago
  To clarify, no, this is a complete non-sequitor. The ability for a type system to do inference has no bearing on whether or not the types are checked or not. To make things even more confusing, as an example, python can have type inference (pytype) or not (mypy). In either case, annotations are type checked.
  - sdht0 6y ago
    The other discussions have already pointed out some limitations in your interpretation (heh) of types. I think the key difference between the annotations in Python and types in Java, or even more strongly in languages like Rust and Haskell, is how they are used in the language ecosystem. In Java and Rust, the types are cental to how programmers think in those languages. A large part of the dev cycle goes into ensuring the types are consistent. In python, these type annotations are a relatively recent addition that the community has not completely adopted yet. A lot of real-world python code will have no types, thus the (3rd party) python type checkers will fail to ensure the benefits of having strong consistent types. And how can we then justify "types" like Object in Java or Any in Rust? Well, sometimes we do want to write code where we want to tell the compiler to stop checking types. However, these are more of an escape hatch rather than a central part of the language ecosystem. As someone else already pointed out, the Java or Rust community does not go about writing code with only Object or Any, even though they can in principle. But in python, that's what the community has been doing till now. It goes the other way too. If the python community starts taking the type annotations seriously, it will start approaching the same usefulness as in these other static languages with good type systems. Then we can start expecting that the 3rd party library type annotations being accurate, which started this discussion in the first place.
    - joshuamorton 6y ago
      > In python, these type annotations are a relatively recent addition that the community has not completely adopted yet. I think you'll find I've said as much elsewhere ;) I think I make essentially the same argument as you do here: https://news.ycombinator.com/item?id=24701113 https://news.ycombinator.com/item?id=24701113
      - sdht0 6y ago
        Yeah sorry, I stopped reading after I felt the discussion was going round in circles. But it's funny how the same viewpoint results in different takeaways. Of course, the topic under discussion is a pedantic one. However, "that's true of any type system" just feels dismissive of the current state of the world. The comment you were replying to was pointing out that at present, enabling strict type checking in Python, that has been bolted on as an add-on only recently, will not be able to provide benefits to the same level as the ones in Java and Rust where types are front and center. That might become true tomorrow when all Python libraries have adopted types. Hypothetically, tomorrow the Rust community could also decide to adopt Any as the central type everyone uses. But today, the state of the world is very different. Python is still known as a dynamically typed language where devs can essentially forget explicit types, and Rust is a strongly statically typed language where devs will rarely have to worry about missing types.
DonaldPShimoda 6y ago
An annotation is when you write some information and it doesn't directly impact the evaluation of that which it annotates. It's a "note", essentially. Type annotations in Python do not actually affect any aspect of runtime and are ignored during evaluation. This is why you need a third-party tool to look at them. You can actually stick any arbitrary code you like after that colon — it's all ignored just the same. What you're referring to are called type ascriptions, and they are often seen in what are sometimes called manifest type systems, where you must explicitly write out your types within a static type system. C and Java are common examples of this. These are not annotations because they have real meaning (either used for declaration or for type conversion). Additionally, there are plenty of statically typed languages which do not require ascription. These languages feature type inference, which is a process that allows the programmer to leave the deduction of the actual types to the compiler. Haskell, Swift, OCaml, Scala, and I think now C++ to some degree (with `auto`) allow for this (to name but a few).
- joshuamorton 6y ago
  > Type annotations in Python do not actually affect any aspect of runtime and are ignored during evaluation. This is equally true in Java. Types are erased at runtime. They don't exist in the bytecode. Just because the type checking and evaluation are done using one tool, "javac" doesn't really mean anything. Again, what's the difference between a bash script that runs mypy prior to invoking python and a bash script that compiles and runs a java program, from the perspective of type safety, assuming you know nothing about the two programs? There is no difference. Neither provides any more guarantees than the other. Put another way, by enforcing use of mypy prior to invocation, you convert the annotation to an ascription. A deeper analysis would suggest that "ascriptions" are actually the things you use to disambiguate when type inference is not powerful enough (https://docs.scala-lang.org/style/types.html https://docs.scala-lang.org/style/types.html). Scala, for example, calls its type declarations "annotations", except when they are needed to disambiguate, when they are "ascriptions". So under the scala definition, python's annotations are exactly the same as scalas as long as they are used for type checking, which, if you use mypy, they are.
  - 6y ago

kobalsky 6y ago

I don't know if mypy allows you to mock the API but at least flow does for javascript. If a library is untyped you get a file with all the exported functions and you can quickly set the types for the functions that you interface with. We have been using this for a couple of years and it's a godsend. There's a community project to share these external library definitions https://github.com/flow-typed/flow-typed https://github.com/flow-typed/flow-typed

DonaldPShimoda 6y ago
That's a neat feature!
- icebraining 6y ago
  You can do the same in mypy by generating a stub file: https://mypy.readthedocs.io/en/stable/stubs.html https://mypy.readthedocs.io/en/stable/stubs.html
  - DonaldPShimoda 6y ago
    ! I had no idea. Super cool — thanks for letting me know!