5 ms·

I've used mypy and pyright. Mypy generally "just works" for all the Python idioms I use, while pyright is less reliable. Pyright's VSCode integration, Pylance,

I've used mypy and pyright. Mypy generally "just works" for all the Python idioms I use, while pyright is less reliable. Pyright's VSCode integration, Pylance, provides a great auto complete experience. So I use Pyright for autocomplete in VSCode and mypy for type checking.

throwaway894345 5y ago
Last I checked, mypy struggled to represent recursive types. Think `JSON = Union[None, bool, str, float, int, List['JSON'], Dict[str, 'JSON']`. That's a bummer because recursive data types are darn handy. Worse, importing third party packages often fails silently and when you can get error messages they tend to be completely inactionable (I recall one error message which linked to a web page that had lots of details and workarounds for fixing other problems, but none of which solved the error itself). Figuring out how to distribute my own type annotations was similarly painful. IIRC, you have to drop a specially-named file into a particular directory and this is all undocumented save for a dense PEP and the error messages are unsurprisingly terrible. All of these things are actionable, but the progress seems slow (these have been among my top grievances since the project debuted, so the maintainers and I have different priorities, clearly). The problems for which I'm less optimistic tend to revolve around shoehorning typing into existing Python syntax--e.g., to get a callback that takes kwargs you have to define a protocol with a `__call__` method that takes kwargs because you can't express it with `typing.Callable`. Similarly where a language with first-class support for types might have `type Foo<T>`, Python makes you write `T = TypeVar("T"); class Foo(Generic[T])` or something like that, and it gets more confusing when you only want one of the methods to be generic and I can never remember whether that `T` takes on a single type across all uses or which scope I need to define it in, etc. This is largely an ergonomic nightmare and I don't have lots of optimism for this stuff to improve unless the Python community really comes to embrace typing as the default way to use Python (but I suspect most people who care a lot about this kind of stuff will leave for Go or other languages where these things just work out of the box).
- codethief 5y ago
  > Similarly where a language with first-class support for types might have `type Foo<T>`, Python makes you write `T = TypeVar("T"); class Foo(Generic[T])` or something like that, and it gets more confusing when you only want one of the methods to be generic and I can never remember whether that `T` takes on a single type across all uses or which scope I need to define it in, etc. I don't know about you but I find PEP 484 very clear here: https://www.python.org/dev/peps/pep-0484/#scoping-rules-for-type-variables https://www.python.org/dev/peps/pep-0484/#scoping-rules-for-...
  - staticassertion 5y ago
    The PEP is clear, it's just extremely unintuitive that, within the scope of declaration, a type T can be many different types.
  - throwaway894345 5y ago
    Fair enough. Maybe I didn't come across that at the time or perhaps it's been since revised. Even still, it's a poor substitution for the more familiar / intuitive `class Foo[T]:` / `def foo[T](...)` style.
    - codethief 5y ago
      Hmm it might take some getting used to but I've actually found it quite straight-forward to comprehend and reason about. The nice thing is that, since TypeVars are ordinary variables, you can re-use them / import them in multiple modules and avoid a lot of boilerplate code.
      - throwaway894345 5y ago
        > The nice thing is that, since TypeVars are ordinary variables, you can re-use them / import them in multiple modules and avoid a lot of boilerplate code. Maybe I'm missing something, but the boilerplate only exists because Python makes you define them as ordinary variables in the first place. So while you can have a `foo.py` file like this: T = TypeVar("T") And a `bar.py` file like this: from foo import T class Bar(Generic[T]): ... So are you saying that this is less boilerplate than a `bar.py` that just defines its own `T` TypeVar? Because that seems like a pretty comparable amount of boilerplate. Or are you saying that it's less boilerplate than languages that don't treat TypeVars as ordinary variables, e.g., Rust? Because in Rust our `bar.rs` file would look like this: `struct Bar<T> {...}` (and the scoping rules are patently obvious, to boot).
mplanchard 5y ago
Seconding this setup for both VSCode and emacs
deleted 5y ago
[deleted]

throwaway894345 5y ago

Last I checked, mypy struggled to represent recursive types. Think `JSON = Union[None, bool, str, float, int, List['JSON'], Dict[str, 'JSON']`. That's a bummer because recursive data types are darn handy. Worse, importing third party packages often fails silently and when you can get error messages they tend to be completely inactionable (I recall one error message which linked to a web page that had lots of details and workarounds for fixing other problems, but none of which solved the error itself). Figuring out how to distribute my own type annotations was similarly painful. IIRC, you have to drop a specially-named file into a particular directory and this is all undocumented save for a dense PEP and the error messages are unsurprisingly terrible. All of these things are actionable, but the progress seems slow (these have been among my top grievances since the project debuted, so the maintainers and I have different priorities, clearly). The problems for which I'm less optimistic tend to revolve around shoehorning typing into existing Python syntax--e.g., to get a callback that takes kwargs you have to define a protocol with a `__call__` method that takes kwargs because you can't express it with `typing.Callable`. Similarly where a language with first-class support for types might have `type Foo<T>`, Python makes you write `T = TypeVar("T"); class Foo(Generic[T])` or something like that, and it gets more confusing when you only want one of the methods to be generic and I can never remember whether that `T` takes on a single type across all uses or which scope I need to define it in, etc. This is largely an ergonomic nightmare and I don't have lots of optimism for this stuff to improve unless the Python community really comes to embrace typing as the default way to use Python (but I suspect most people who care a lot about this kind of stuff will leave for Go or other languages where these things just work out of the box).

codethief 5y ago
> Similarly where a language with first-class support for types might have `type Foo<T>`, Python makes you write `T = TypeVar("T"); class Foo(Generic[T])` or something like that, and it gets more confusing when you only want one of the methods to be generic and I can never remember whether that `T` takes on a single type across all uses or which scope I need to define it in, etc. I don't know about you but I find PEP 484 very clear here: https://www.python.org/dev/peps/pep-0484/#scoping-rules-for-type-variables https://www.python.org/dev/peps/pep-0484/#scoping-rules-for-...
- staticassertion 5y ago
  The PEP is clear, it's just extremely unintuitive that, within the scope of declaration, a type T can be many different types.
- throwaway894345 5y ago
  Fair enough. Maybe I didn't come across that at the time or perhaps it's been since revised. Even still, it's a poor substitution for the more familiar / intuitive `class Foo[T]:` / `def foo[T](...)` style.
  - codethief 5y ago
    Hmm it might take some getting used to but I've actually found it quite straight-forward to comprehend and reason about. The nice thing is that, since TypeVars are ordinary variables, you can re-use them / import them in multiple modules and avoid a lot of boilerplate code.
    - throwaway894345 5y ago
      > The nice thing is that, since TypeVars are ordinary variables, you can re-use them / import them in multiple modules and avoid a lot of boilerplate code. Maybe I'm missing something, but the boilerplate only exists because Python makes you define them as ordinary variables in the first place. So while you can have a `foo.py` file like this: T = TypeVar("T") And a `bar.py` file like this: from foo import T class Bar(Generic[T]): ... So are you saying that this is less boilerplate than a `bar.py` that just defines its own `T` TypeVar? Because that seems like a pretty comparable amount of boilerplate. Or are you saying that it's less boilerplate than languages that don't treat TypeVars as ordinary variables, e.g., Rust? Because in Rust our `bar.rs` file would look like this: `struct Bar<T> {...}` (and the scoping rules are patently obvious, to boot).

mplanchard 5y ago

Seconding this setup for both VSCode and emacs

deleted 5y ago

[deleted]