3 ms·

I love typing. But python's type annotation is absolute garbage. The fact that you need to import types should tell you what a load of shit it is. All files now

I love typing. But python's type annotation is absolute garbage. The fact that you need to import types should tell you what a load of shit it is. All files now have type imports. Yuck. In addition, the only way type annotations are effective is if you use an editor that can parse types. Yuck. Lastly, it is far too easy to create complex types with questionable value all over your code. Any time a developer wants to unravel a pre-existing complex type, it feels like working with C++. It's utter garbage.

kajaktum 4y ago
>Lastly, it is far too easy to create complex types with questionable value all over your code. Any time a developer wants to unravel a pre-existing complex type, it feels like working with C++. It's utter garbage. No. Having types is always better than not. If you have a complex functionality, it is going to have a complex type. But now you KNOW its complex and not have to unravel its complexity for the 5th time this month. I had to write something like this recently: ``` pub SearchInfo { matches: Arc<HashMap<PathBuf, Vec<(usize, (usize, usize), String)>>> } ``` This is complex, yes, but just by reading the type and names given to it: 1. `Arc`. So that means it can be safely shared across thread. 2. `HashMap` from `PathBuf` to `X`. So I am probably mapping file/folders to X. 3. `Vec<(usize, (usize, usize), String)>`. So the first `usize` denotes the line number. `(usize,usize)` denotes the start and end characters and the `String` is the whole line itself! Just imagine unraveling this whole crap if its all simply a JavaScript `Object`.
- pkolaczk 4y ago
  It would be probably better if you haven't used naked usize, but wrapped it into a new type. When I find types get complex, I introduce type aliases or structs. That X in your signature likely deserves a name.
- tipsytoad 4y ago
  I'd convert that last tuple to struct, unlike the rest of the type it's undecipherable without some kind of documentation.
gbear605 4y ago
You can (and should) use mypy as part of your pipeline if you use type annotations, and that verifies that your types are correct without needing to use a special editor.
- xmcqdpt2 4y ago
  Also mypy is super easy to use. You just run it on your repo root and it automatically checks everything. It's perfectly well-suited to CLI based dev workflows.
- pkolaczk 4y ago
  That doesn't work when many libraries don't use type annotations.
- nine_zeros 4y ago
  > You can (and should) use mypy as part of your pipeline if you use type annotations, and that verifies that your types are correct without needing to use a special editor. As software engineers, if you are relying on CI to verify language features, you are going backwards in time.
  - dimator 4y ago
    It's not ci, it's part of your (local) build.
    - icedchai 4y ago
      Not in my experience. If it's in your local build, it also needs to be in CI. Otherwise mistakes can easily slip through.
      - ElevenLathe 4y ago
        The point is it can be both places: locally during hacking and in CI to prevent accidentally pushing broken builds.
hbrn 4y ago
What type imports are you talking about? https://peps.python.org/pep-0585/ https://peps.python.org/pep-0585/ has been implemented in Python 3.9.

kajaktum 4y ago

>Lastly, it is far too easy to create complex types with questionable value all over your code. Any time a developer wants to unravel a pre-existing complex type, it feels like working with C++. It's utter garbage. No. Having types is always better than not. If you have a complex functionality, it is going to have a complex type. But now you KNOW its complex and not have to unravel its complexity for the 5th time this month. I had to write something like this recently: ``` pub SearchInfo { matches: Arc<HashMap<PathBuf, Vec<(usize, (usize, usize), String)>>> } ``` This is complex, yes, but just by reading the type and names given to it: 1. `Arc`. So that means it can be safely shared across thread. 2. `HashMap` from `PathBuf` to `X`. So I am probably mapping file/folders to X. 3. `Vec<(usize, (usize, usize), String)>`. So the first `usize` denotes the line number. `(usize,usize)` denotes the start and end characters and the `String` is the whole line itself! Just imagine unraveling this whole crap if its all simply a JavaScript `Object`.

pkolaczk 4y ago
It would be probably better if you haven't used naked usize, but wrapped it into a new type. When I find types get complex, I introduce type aliases or structs. That X in your signature likely deserves a name.
tipsytoad 4y ago
I'd convert that last tuple to struct, unlike the rest of the type it's undecipherable without some kind of documentation.

gbear605 4y ago

You can (and should) use mypy as part of your pipeline if you use type annotations, and that verifies that your types are correct without needing to use a special editor.

xmcqdpt2 4y ago
Also mypy is super easy to use. You just run it on your repo root and it automatically checks everything. It's perfectly well-suited to CLI based dev workflows.
pkolaczk 4y ago
That doesn't work when many libraries don't use type annotations.
nine_zeros 4y ago
> You can (and should) use mypy as part of your pipeline if you use type annotations, and that verifies that your types are correct without needing to use a special editor. As software engineers, if you are relying on CI to verify language features, you are going backwards in time.
- dimator 4y ago
  It's not ci, it's part of your (local) build.
  - icedchai 4y ago
    Not in my experience. If it's in your local build, it also needs to be in CI. Otherwise mistakes can easily slip through.
    - ElevenLathe 4y ago
      The point is it can be both places: locally during hacking and in CI to prevent accidentally pushing broken builds.

hbrn 4y ago

What type imports are you talking about? https://peps.python.org/pep-0585/ https://peps.python.org/pep-0585/ has been implemented in Python 3.9.