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

51–60 of 118 posts

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

#51

Post by codethief »

throwaway894345 wrote: post #46
codethief wrote: post #37

Earlier quoted context omitted.

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…

No, in this particular example, there's no real advantage. What I meant were situations where the TypeVar gets a little more complicated, compare the additional parameters on https://docs.python.org/3/library/typing.html#typing.TypeVar . Then importing TypeVars starts to pay off because you only have to define your bounds etc. once.

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

#52

Post by nickm12 »

tomwojcik wrote: post #48
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…

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.

I'm not sure what you mean by "cannot be understood well". Either the type annotation is correct or not. If there is a genuine bug in mypy, the recommended convention is to use "type: ignore" (ideally with a reference to a bug tracking id). If you are genuinely subverting the typesystem, then use a cast(). If the code is too complex to type correctly or the type cannot be expressed in the typesystem (e.g. recursive types) then use type Any.

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

#53

Post by Mehdi2277 »

erjiang wrote: post #49
Demiurge wrote: post #44

Earlier quoted context omitted.

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…

Not that much as they all follow pep 484 + a few other peps. The number of type features unique to each one are generally bugs/recent peps they haven't implemented. The biggest one is mypy plugin ecosystem although the hope there is to either do more peps that plugins become no longer needed and the type system is strong enough to cover more things or make a plugin pep.

If you are using the most recent pep features possible than yeah you might have an issue. That's similar to clang/gcc both taking time to implement new c++ standards and not being compatible there. If you only use pep 484 which covers most basics well then you should be good for any checker.

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

#54

Post by nickm12 »

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've been on teams at multiple companies that have used type annotations for Python. Developers have generally loved adopting type annotations because it (1) makes the code easier to understand (2) makes the code easier to refactor (3) improves integration with IDEs and (4) catches real bugs.

I disagree that type errors "aren't practically a problem". NoneType errors and AttributeErrors turn up all the time in Python.

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

#55

Post by 6gvONxR4sf7o »

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…

Whichever option you take, stick it into pre-commit. A good pre-commit-config.yaml is quality-of-life changing.

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

#56

Post by whimsicalism »

kbumsik wrote: post #50
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?

Yes, in house

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

#57

Post by whimsicalism »

Demiurge wrote: post #38
dunefox wrote: post #10

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

... is there some problem with having multiple choices of libraries?

I think it'd be nice if they settled on a standard as to what is a correctly typed program.

Mypy and Pyre are pretty similar, but Pytype has very different standards.

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

#58

Post by whimsicalism »

Demiurge wrote: post #40
short_sells_poo wrote: post #32

Earlier quoted context omitted.

It's starting to look like the huge embarrassment that is python packaging and environment management. I work with the language every day, and I still have no idea what am I supposed to use between conda, pip, setuptools/setup.py, pyproject, meta.yml, poetry, pipenv, etc... Conda is so slow that I sometimes wonder if we are being trolled by some cruel God of programming. Pip is faster, but version resolution is iffy.…

There are actually clear answers to all your questions. All the tools you listed do different things, except maybe poetry and pipenv, so you can pick whichever one you like, you're not supposed to do anything. You can have choice, illusion of free will, etc... As to module version, there is a standard on how to define it in __version__: https://www.python.org/dev/peps/pep-0008/#module-level-dunde...

> There are actually clear answers to all your questions.

Strongly disagree. Conda, pipenv, pyenv, venv, poetry are all trying to solve the same problem (although conda tries to solve some other problems too).

Choice is not always good, this is why we have standards.

I would recommend pyenv. I understand why people are attracted to poetry, but pyenv arguably offers all of the same benefits that poetry has as well, and has better adoption.

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

#59

Post by throwaway894345 »

codethief wrote: post #51
throwaway894345 wrote: post #46

Earlier quoted context omitted.

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

No, in this particular example, there's no real advantage. What I meant were situations where the TypeVar gets a little more complicated, compare the additional parameters on https://docs.python.org/3/library/typing.html#typing.TypeVar . Then importing TypeVars starts to pay off because you only have to define your bounds etc. once.

Ah, that makes sense. Thanks for clarifying.

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

#60

Post by bobbylarrybobby »

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.

It's not just about type errors. (Good) autocomplete and documentation are only available when types are either explicitly labeled or correctly inferred. It's important that I be able to 1. type in just the first few letters of a method name and press to complete it, and 2. hover over a method's name and get docs for the method. Both of these are only reliable if the type of the caller is known.
Post reply on HN