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

41–50 of 118 posts

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

#41

Post by flakiness »

zem wrote: post #25
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…

have you had any problems using the open source version of pytype? we've tried to make it easy to just drop in to your setup.cfg and automatically analyse an entire project; if there are things that don't work we'd love bug reports for them!

No. I didn't expect it to be non-blaze/bazel tool friendly, but sounds like it is (aims to be at lest)?

It does seems to support the entire-directory parsing as well. That's nice! Let me give it a try next time. Thanks for the tip!

As a reminder to myself, here is the link to the doc: https://google.github.io/pytype/

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

#42

Post by nerdponx »

vorticalbox wrote: post #36
nerdponx wrote: post #23

Earlier quoted context omitted.

PyCharm having type checking built in is excellent, but it is definitely the lowest quality out of the major 3 (Mypy, Pyright, Pyre) with respect to correctness.

I've always found its type checking to be perfectly fine, but hearing its not the best I might look into the others.

It tends to be overly-lenient about certain return types and tends to miss some more advanced type inferences.

It's a great tool when editing code. But you still should run Mypy or another checker for more-correct analysis.

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

#43

Post by staticassertion »

Groxx wrote: post #34
staticassertion wrote: post #15

Earlier quoted context omitted.

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'…

This pretty much mirrors my mypy experience too. The only project I've ever successfully used it on was a single-file CLI tool that only used the stdlib. And by "successfully" I mean "it ran at all". Every other thing I've thrown at it has caused it to crash. I quite like the concept, but implementation has been rather abysmal as far as I've seen. Has it improved in ~ the past year?

Not really, no.

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

#44

Post by Demiurge »

a3w wrote: post #21

A Tale of two types systems -> now: a Tale of three types systems? To make it a book title, The three type systems problem?

How are three type systems? The type annotations are part of the Python 3. You can use multiple libraries to analyze the types. There are also multiple static type analysis tools for C, and for other languages that have type definitions as part of the language. How is this an issue, what am I missing something?

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

#45

Post by mumblemumble »

globular-toast wrote: post #35

Anyone considering using type hints should listen to this talk: https://www.infoq.com/presentations/dynamic-static-typing/ I personally think it's mostly a waste of time to do type hinting for the purpose of catching errors in a strongly typed language like Python. Type errors just aren't practically a problem in dynamic languages. Doing types for performance is a great reason to do it, though.

I agree with you that the benefits of static typing are sometimes greatly exaggerated. But I also think that using type hints and type checkers in Python isn't quite the same thing as static typing.

For starters, type checking can't actually guarantee you won't have type errors at run time. Because, unlike in a statically typed language, in Python, anyone can always choose to just not use type hinting. Whenever that happens, as far as the type checker is concerned, anything goes.

But type hints are very useful as hints. They help with editor tooling, which can make it easier to navigate an unfamiliar codebase. They provide extra information that makes the code easier to read. And they give me an opt-in form of type linting that allows me to set up regions of code where I don't have to take quite so much personal responsibility for ensuring that arguments are compatible with parameters. In short, it's not a correctness prover; it's an energy saver.

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

#46

Post by throwaway894345 »

codethief wrote: post #37
throwaway894345 wrote: post #19

Earlier quoted context omitted.

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.

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.

> 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 {...}` (and the scoping rules are patently obvious, to boot).

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

#48

Post by tomwojcik »

flakiness wrote: post #3
azhenley wrote: post #2

Big discussion with over 500 comments from 3 years ago: https://news.ycombinator.com/item?id=17048446

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…

I'd advise to give mypy yet another try but disable in config file error codes that are painful and # noqa or # type: ignore lines that can't be understood well by mypy.

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

#49

Post by erjiang »

Demiurge wrote: post #44
a3w wrote: post #21

A Tale of two types systems -> now: a Tale of three types systems? To make it a book title, The three type systems problem?

How are three type systems? The type annotations are part of the Python 3. You can use multiple libraries to analyze the types. There are also multiple static type analysis tools for C, and for other languages that have type definitions as part of the language. How is this an issue, what am I missing something?

When you write types in Python, the interpretation of your type annotations are up to the type checker. Your annotations that you write for e.g. Pyre may not type check in mypy. The end result is that your type annotations are not "Python" type annotations, but "Pyre"/"mypy"/etc. type annotations.

In C, you ultimately care about what the compiler says. And this has also led to dialect-specific C code that works fine in one compiler but doesn't compile or runs incorrectly in another compiler.

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

#50

Post by kbumsik »

jmugan wrote: post #20

PyCharm works well for me. Probably not as fancy as all this other stuff, but the type hints make the code easier to understand, and they help PyCharm help me by enabling it to find more errors and by enabling enhanced autocompletion.

What type checker does PyCharm use? In-house?
Post reply on HN