5 ms·

There's nothing stopping you doing that in Python. If it's important to you to define a point struct, do that, add a type annotation, and add mypy to your compi

There's nothing stopping you doing that in Python. If it's important to you to define a point struct, do that, add a type annotation, and add mypy to your compile. When i used to work with C++ i would spend hours debugging compile issues that were just the wrong type (templates are especially bad!) that really had no impact on the code, it was just a waste of my time. What I like about python is that the static typing is there if you want it, but you don't have to.

still_grokking 5y ago
To my knowledge Python doesn't have any sound type system. Mypy doesn't provide that. So, no you can't have (currently) proper static typing in Python. It's more like in TypeScript where it's a best effort thing. (At least you get notified when the typer gives up. That's much better than nothing of course!) C++ templates aren't a good example either. Templates are a Turning complete language so they can't provide guaranties in all cases and aren't as such type safe at all. Better examples for type systems and their usefulness would be languages form the ML family (also including Haskell and similar in this case).
- CraigJPerry 5y ago
  >> Python doesn't have any sound type system Neither do popular statically typed languages like Scala, Java, C#, … - sound in the context of PL theory means the type checker will only accept a correctly typed program. Which is not true for any of these languages i mentioned - you can get the compiler to accept an incorrectly typed program. >> you can't have (currently) proper static typing in Python That’s an even bigger group of languages in that bucket, typing is undecidable in “favourite” languages like Rust, ocaml, c++, f#
  - still_grokking 5y ago
    Scala's base caluculus is proven sound! The implemented language as such has minor soundness holes, correct. But you need to resort to "murky" parts (like combinations of null, top and bottom types and sub-type relationships between them) to exploit this. In practice I've never run into any case of this soundness holes. You need to explicitly construct a pathological case. (Just avoid null and you should be safe in any case afik). This can't be said about things like MyPy or TS. There you run into soundness holes on a daily basis. OCaml and F# are undecidable? Also because of sub-typing? And what's the problem with Rust? It doesn't have sub-typing. The problems with sub-typing in general could go away in the future when algebraic sub-typing catches on.
mynameisash 5y ago
I have several problems with this: * I have had the installation of mypy fail on multiple machines and crash (‽) several machines * mypy is a separate component; yes, it's very well supported, but it's not included with python3 by default * It's not required by packages to function, which means that packages can and do simply neglect to add typings. The package I used in my example doesn't provide any such typing information, so me using mypy wouldn't help * Besides mypy, the package in question lacks appropriate documentation (eg, the mouseover of the function I was calling provided nothing in the IDE to give a hint). The method signature defines the shape parameter as being named "xy". Only when I went to the web site did I find that it's supposed to be either List[int, int, int, int] or List[Tuple[int, int], Tuple[int, int]] and that the second pair of values is a point and not dimensions. Were I doing this in another language, the type annotation would likely provide some details. This is my problem with Python -- yes, you can use typing hints if you want, but nowhere is it required. This leads to a world in which I spend 45 minutes painfully debugging this kind of thing only after my code is written. In my experience, this type of bug very rarely exists in stricter, compiled languages.

still_grokking 5y ago

To my knowledge Python doesn't have any sound type system. Mypy doesn't provide that. So, no you can't have (currently) proper static typing in Python. It's more like in TypeScript where it's a best effort thing. (At least you get notified when the typer gives up. That's much better than nothing of course!) C++ templates aren't a good example either. Templates are a Turning complete language so they can't provide guaranties in all cases and aren't as such type safe at all. Better examples for type systems and their usefulness would be languages form the ML family (also including Haskell and similar in this case).

CraigJPerry 5y ago
>> Python doesn't have any sound type system Neither do popular statically typed languages like Scala, Java, C#, … - sound in the context of PL theory means the type checker will only accept a correctly typed program. Which is not true for any of these languages i mentioned - you can get the compiler to accept an incorrectly typed program. >> you can't have (currently) proper static typing in Python That’s an even bigger group of languages in that bucket, typing is undecidable in “favourite” languages like Rust, ocaml, c++, f#
- still_grokking 5y ago
  Scala's base caluculus is proven sound! The implemented language as such has minor soundness holes, correct. But you need to resort to "murky" parts (like combinations of null, top and bottom types and sub-type relationships between them) to exploit this. In practice I've never run into any case of this soundness holes. You need to explicitly construct a pathological case. (Just avoid null and you should be safe in any case afik). This can't be said about things like MyPy or TS. There you run into soundness holes on a daily basis. OCaml and F# are undecidable? Also because of sub-typing? And what's the problem with Rust? It doesn't have sub-typing. The problems with sub-typing in general could go away in the future when algebraic sub-typing catches on.

mynameisash 5y ago

I have several problems with this: * I have had the installation of mypy fail on multiple machines and crash (‽) several machines * mypy is a separate component; yes, it's very well supported, but it's not included with python3 by default * It's not required by packages to function, which means that packages can and do simply neglect to add typings. The package I used in my example doesn't provide any such typing information, so me using mypy wouldn't help * Besides mypy, the package in question lacks appropriate documentation (eg, the mouseover of the function I was calling provided nothing in the IDE to give a hint). The method signature defines the shape parameter as being named "xy". Only when I went to the web site did I find that it's supposed to be either List[int, int, int, int] or List[Tuple[int, int], Tuple[int, int]] and that the second pair of values is a point and not dimensions. Were I doing this in another language, the type annotation would likely provide some details. This is my problem with Python -- yes, you can use typing hints if you want, but nowhere is it required. This leads to a world in which I spend 45 minutes painfully debugging this kind of thing only after my code is written. In my experience, this type of bug very rarely exists in stricter, compiled languages.