Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyre: A performant type-checker for Python 3

pyre-check.org

Post reply on HN
Print view View original

11–20 of 118 posts

Re: Pyre: A performant type-checker for Python 3

#11

Post by flakiness »

Mehdi2277 wrote: post #7
hiq wrote: post #4

Earlier quoted context omitted.

As someone who hasn't started using types in Python seriously yet, it's a bit discouraging to see that there are already so many competing type checkers with different approaches and no clear winner. I understand that the problem is a bit harder than `{go, cargo} fmt`, but I feel we'd be better off with one type checker to rule them all. Or does it mean that we should check types using all type-checkers available to…

In practice they are quite similar in errors reported. There are differences that pop up but most of the time either it is bug to report or one has implemented a certain pep faster than another. A few rare things are extra type checking support entirely like pyright supports recursive types but mypy does not (or pyre has best tensor related support but those are future peps). Mypy's biggest unique thing is plugin sup…

Thanks for the tip! Posting link here for the reference: https://us.pycon.org/2021/summits/typing/

Hope they post the recordings somewhere later.

Re: Pyre: A performant type-checker for Python 3

#12

Post by codethief »

throwaway894345 wrote: post #8
MapleWalnut wrote: post #6

Earlier quoted context omitted.

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.

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…

> Similarly where a language with first-class support for types might have `type Foo`, 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-...

Re: Pyre: A performant type-checker for Python 3

#13

Post by staticassertion »

codethief wrote: post #12
throwaway894345 wrote: post #8

Earlier quoted context omitted.

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…

> Similarly where a language with first-class support for types might have `type Foo `, 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 4…

The PEP is clear, it's just extremely unintuitive that, within the scope of declaration, a type T can be many different types.

Re: Pyre: A performant type-checker for Python 3

#14

Post by codethief »

throwaway894345 wrote: post #8
MapleWalnut wrote: post #6

Earlier quoted context omitted.

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.

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…

> 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`

You might be interested in the discussion over here then -> https://github.com/python/typing/issues/769#issuecomment-741...

Re: Pyre: A performant type-checker for Python 3

#15

Post by staticassertion »

throwaway894345 wrote: post #8
MapleWalnut wrote: post #6

Earlier quoted context omitted.

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.

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…

I have yet to successfully build a project with the strict mypy settings, without resorting to either turning some off or having to use an explicit Any. And a lot of the non-default settings are absolutely critical if you care about correctness.

Lack of recursive types has been a major deal breaker for me. If you have a class Foo that can construct a class Bar, and a class Bar that can construct a class Foo, you can't express that in mypy without Any-Generics.

To me, at this point, mypy is barely a linter, it's more of a "this helps my IDE autocomplete faster", and definitely not a type system.

Re: Pyre: A performant type-checker for Python 3

#17

Post by IshKebab »

dunefox wrote: post #10

As with package managers, there seem to be half a dozen different, competing type checkers for Python now...

Yeah and even worse they disagree about type errors!

We really need a modern Python alternative. I don't know of any that don't give up the REPL / single file script features which are pretty huge advantages of Python to be honest.

Re: Pyre: A performant type-checker for Python 3

#18

Post by ben509 »

hiq wrote: post #4
flakiness wrote: post #3

Earlier quoted context omitted.

So three years passed and static checkers have gotten even more traction. What's the best option for Python so far for small projects today? I tried mypy [1] before but it was a bit cumbersome to keep it checking my code. At work I use pytype [2]. It's good enough but that's only because someone else made a build system integration for me. Pyre's scan-all-the-files approach seems easier to get started. Is there any c…

As someone who hasn't started using types in Python seriously yet, it's a bit discouraging to see that there are already so many competing type checkers with different approaches and no clear winner. I understand that the problem is a bit harder than `{go, cargo} fmt`, but I feel we'd be better off with one type checker to rule them all. Or does it mean that we should check types using all type-checkers available to…

No, multiple checkers will drive you crazy because one type checker will support one feature while another will report errors for it.

Re: Pyre: A performant type-checker for Python 3

#19

Post by throwaway894345 »

codethief wrote: post #12
throwaway894345 wrote: post #8

Earlier quoted context omitted.

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…

> Similarly where a language with first-class support for types might have `type Foo `, 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 4…

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.
Post reply on HN