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

71–80 of 118 posts

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

#71

Post by j1elo »

Unrelated funny little fact for lovers of scifi novels: Pyre (PyrE) was the name of an extremely rare element and main plot device for the novel Tiger! Tiger! (aka. "The Stars My Destination"), by Alfred Bester:

https://www.amazon.com/dp/B01MRJVUPC/

Maybe not the best science fiction book of all times, but it left a mark on my memory... and curious things like this name have stayed there since when I was a kid avidly reading everything that fell on his hands :-)

-- EDIT: Link to the book

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

#72

Post by joshuamorton »

whimsicalism wrote: post #58
Demiurge wrote: post #40

Earlier quoted context omitted.

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

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

Not really, some of these manage the issue of multiple system pythons (pyenv), while some manage isolated envs for particular projects (venv), and some try to be wholistic python project and dependency managers (pipenv, poetry, arguably venv + pip freeze, but that's not "wholistic"). Conda sort of tries to be all of the above as well as a bunch of other things (high performance options etc.)

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

#73

Post by joshuamorton »

globular-toast wrote: post #68
nickm12 wrote: post #54

Earlier quoted context omitted.

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.

Fwiw this absolutely doesn't match my experience with pytype, both on my own work and, as I understand it, "at scale".

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

#74

Post by whimsicalism »

joshuamorton wrote: post #72
whimsicalism wrote: post #58

Earlier quoted context omitted.

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

> Strongly disagree. Conda, pipenv, pyenv, venv, poetry are all trying to solve the same problem (although conda tries to solve some other problems too). Not really, some of these manage the issue of multiple system pythons (pyenv), while some manage isolated envs for particular projects (venv), and some try to be wholistic python project and dependency managers (pipenv, poetry, arguably venv + pip freeze, but that's…

Pyenv also has isolated envs for specific projects, poetry also tries to solve that problem.

There is a ton of overlap, denying that is disingenuous.

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

#75

Post by [deleted] »

flowerlad wrote: post #65
mumblemumble wrote: post #45

Earlier quoted context omitted.

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.

[deleted]

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

#76

Post by staticassertion »

Mehdi2277 wrote: post #53
erjiang wrote: post #49

Earlier quoted context omitted.

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

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

This is totally untrue? Pyre adds completely new notions like taint analysis, pytype adds a totally different inference system - the type systems are not compatible and it has nothing to do with implementation of PEPs.

The difference with C is that all of the other linters and analyzers are on top of the base type system, they don't replace it. In the case of Python the only standard part is where the annotations go and how they get resolved at runtime, it's otherwise completely up to the type system implementation to determine what's what, and all 3 of them do so in very different ways.

This is like if clang/gcc had totally different behaviors for `auto` in C++, but really it's not even comparable.

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

#77

Post by Mehdi2277 »

staticassertion wrote: post #76
Mehdi2277 wrote: post #53

Earlier quoted context omitted.

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

> 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. This is totally untrue? Pyre adds completely new notions like taint analysis, pytype adds a totally different inference system - the type systems are not compatible and it has nothing to do with implementation of PEPs. The difference with C is that all…

The inference system and the type system are separate. Pyright uses a very different inference algorithm than mypy for better incremental support. It remains pep 484 compliant like mypy. Pyre's taint analysis is separate from pep 484 and is something different from type checking. Pyre explicitly describes taint analysis as separate from base type checking, "Pyre has applications beyond type checking python code: it can also run static analysis, more specifically called Taint Analysis, to identify potential security issues. "

My base statement of 4 main type checkers are pep 484 compliant and that's main type checking most people refer to for python. If you get a type error that's inconsistent with that pep that's a bug. If you use a feature outside of any pep like plugins, taint analysis, pyright stub generation, then yes that is unspecified and can vary. Most engineers I work with python type checking stops mostly at basic type system and I'll sometimes point them to newer peps for better type definitions. My actual experience is most places don't consistently do any type checking at all although people tend to be open to it if you're fine guiding them/setting it up.

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

#78

Post by aflag »

globular-toast wrote: post #68
nickm12 wrote: post #54

Earlier quoted context omitted.

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.

Fixing 1-2% of the errors in real world projects is nice, isn’t it? Not to mention catching the non real world errors before even running any tests.

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

#79

Post by N1H1L »

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

Try mamba instead of conda [0]. It's really fast.

The first time you have to run it as:

    conda install -c conda-forge mamba
From then on, you replace conda with mamba. For example, if you are installing dask-cuda from the rapidsai channel you run it as:

    mamba install -c rapidsai dask-cuda
At this point, mamba is just so much better and faster, that it's the first package I install in an Anaconda environment.

[0] https://github.com/mamba-org/mamba

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

#80

Post by N1H1L »

onerandompotato wrote: post #31
IshKebab wrote: post #17

Earlier quoted context omitted.

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.

Wouldn't Julia be that language? Its fast, supports static typing, and is built from the ground up for machine learning/ data science. It also has a built in REPL.

Julia is that language now. Previously I had sunk cost fallacy regarding Python, but now we are building a brand new application from scratch, and we chose Julia.
Post reply on HN