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

61–70 of 118 posts

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

#61

Post by endgame »

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…

    $ python -c 'import this' | sed -n 15p
    There should be one-- and preferably only one --obvious way to do it.
Sadly, the python type-checking situation appears to be going the way of the python packaging situation.

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

#62

Post by [deleted] »

MapleWalnut wrote: post #6
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'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.

[deleted]

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

#63

Post by Demiurge »

whimsicalism wrote: post #57
Demiurge wrote: post #38

Earlier quoted context omitted.

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

If type analysis tools show different issues, fixing one should not break the other, unless the other is wrong? They both are trying to model the same language/runtime.

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

#64

Post by jchonphoenix »

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…

Mypy and Pyre appear to be the only two that work really well and can solve type-checking issues at scale.

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

#65

Post by flowerlad »

mumblemumble wrote: post #45
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…

> I agree with you that the benefits of static typing are sometimes greatly exaggerated.

For large, multi-developer projects, it is impossible to exaggerate the benefits of static typing.

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

#66

Post by mvzvm »

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 a problem the moment it has to interact with the outside world, especially DBs/serialization/... really any kind of I/O.

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

#67

Post by lacker »

short_sells_poo wrote: post #32
dunefox wrote: post #10

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

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

I feel like the problem is that pip is clearly the most popular, but philosophically the pip developers do not want to build a solution to all packaging and environment management into pip.

If I were pip dictator, I would try to make pip the one tool to handle all python packaging and environment management. In particular, that means pip would handle the management of different Python versions, different Python environments, native dependencies, running tests, making builds perfectly reproducible, releasing new versions of libraries, and creating new projects.

"Creating new projects" seems like it is not a big deal, but in practice I think that if there were simply a "pip new" command that set up a new project using the best practices advocated by the pip team, it would go a long way toward standardizing the ecosystem here.

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

#68

Post by globular-toast »

nickm12 wrote: post #54
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…

Clearly didn't watch the talk then. He found that about 1-2% of errors in real world projects were type-related errors.

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

#69

Post by globular-toast »

bobbylarrybobby wrote: post #60
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.

But we're commenting on a type checker which implies this is being done to catch errors.

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

#70

Post by globular-toast »

mvzvm wrote: post #66
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 a problem the moment it has to interact with the outside world, especially DBs/serialization/... really any kind of I/O.

So Python can't do IO? Django doesn't exist? What are you talking about exactly?
Post reply on HN