8 ms·

Why? Just use mypy and disable Any types. So, it's not longer optional. Then make it so that if mypy fails, your code doesn't run. test-all: mypy ma

Why? Just use mypy and disable Any types. So, it's not longer optional. Then make it so that if mypy fails, your code doesn't run. test-all: mypy main.py pytest test/main.py

lozenge 6y ago
This relies on your third party library type annotations being accurate.
- joshuamorton 6y ago
  That's true of any type system.
  - DonaldPShimoda 6y ago
    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
      - 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!
- philwelch 6y ago
  Or existing in the first place. Or being fundamentally possible to implement in the first place (I say, glaring at boto3).
  - orf 6y ago
    mypy-boto3 works fantastically: https://mypy-boto3.readthedocs.io/en/latest/ https://mypy-boto3.readthedocs.io/en/latest/
    - philwelch 6y ago
      Huh, interesting: > Auto discovery of types for boto3.client and boto3.session calls I'm curious how this is possible. I didn't realize mypy could inspect function arguments and use them to determine the returned type.
      - duckerude 6y ago
        typing.Literal makes a lot possible as of 3.8: https://docs.python.org/3/library/typing.html#typing.Literal https://docs.python.org/3/library/typing.html#typing.Literal
- hsbauauvhabzb 6y ago
  At one point there was exactly zero support for python3 by third party libraries, it took >10 years but we got there. I see it as ‘use strict’ in JS land
ebg13 6y ago
> Just use mypy Mypy doesn't work for code that isn't statically available before runtime. Though there are ways to do runtime type checking as well.

Why? Just use mypy and disable Any types. So, it's not longer optional. Then make it so that if mypy fails, your code doesn't run. test-all: mypy main.py pytest test/main.py

lozenge 6y ago

This relies on your third party library type annotations being accurate.

joshuamorton 6y ago
That's true of any type system.
- DonaldPShimoda 6y ago
  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
    - 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!
philwelch 6y ago
Or existing in the first place. Or being fundamentally possible to implement in the first place (I say, glaring at boto3).
- orf 6y ago
  mypy-boto3 works fantastically: https://mypy-boto3.readthedocs.io/en/latest/ https://mypy-boto3.readthedocs.io/en/latest/
  - philwelch 6y ago
    Huh, interesting: > Auto discovery of types for boto3.client and boto3.session calls I'm curious how this is possible. I didn't realize mypy could inspect function arguments and use them to determine the returned type.
    - duckerude 6y ago
      typing.Literal makes a lot possible as of 3.8: https://docs.python.org/3/library/typing.html#typing.Literal https://docs.python.org/3/library/typing.html#typing.Literal
hsbauauvhabzb 6y ago
At one point there was exactly zero support for python3 by third party libraries, it took >10 years but we got there. I see it as ‘use strict’ in JS land

ebg13 6y ago

> Just use mypy Mypy doesn't work for code that isn't statically available before runtime. Though there are ways to do runtime type checking as well.