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

91–100 of 118 posts

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

#91

Post by DickieStarshine »

N1H1L wrote: post #79
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.…

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

That's exactly the problem: instead of using conda you should instead use one of the myriad of others! It's balkanisation.

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

#92

Post by ErikBjare »

whimsicalism wrote: post #74
joshuamorton wrote: post #72

Earlier quoted context omitted.

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

While there is overlap, there's also a ton of differences (pyproject for dependencies, dependency resolution, version locks).

I use both pyenv and poetry, and basically nothing else apart from the occasional call to pip.

I cannot imagine dropping poetry and only use pyenv, but I can imagine dropping pyenv (have been looking at asdf recently...)

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

#93

Post by IshKebab »

zelphirkalt wrote: post #89
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.

GNU Guile can do that easily, as probably many other languages. The ecosystem is what makes people stick to Python, especially in areas like data science. Ecosystems are generally difficult to compete with, because they rely a lot on mind share. Mind share is a bit like gravity, in that clumps of matter will collect more matter. It takes very motivated people to implement solutions anew in another language, piece by…

GNU Guile is a weird Lisp variant. Nobody is switching from Python to that; be realistic.

I do agree in some applications like data science / machine learning you could never get people to switch from Python because everyone uses it. But Python is also used for loads of other things, e.g. hacky build systems, web scraping, etc. that could easily switch.

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

#94

Post by IshKebab »

DickieStarshine wrote: post #90
IshKebab wrote: post #85

Earlier quoted context omitted.

Julia is nothing like Python though, and it has other flaws like 1-based indexing and huge delays loading packages as it compiles them.

How is it nothing like Python? 1-based indexing is definitely not a flaw. And version 1.6 massively decreased package import and precompilation time.

> 1-based indexing is definitely not a flaw.

It really is. We've known it for literally decades:

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

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

#95

Post by marcusbuffett »

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.

I have to really question how the study was conducted if only 1-2% of python errors were considered type errors. Even if the only type error you consider is None vs not None, you'd get more than that. Certainly those errors account for more than 1% of the errors I see in my own professional experience using Python. I'm curious what his reasoning was so I'll watch the talk, but there's something screwy there.

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

#96

Post by joshuamorton »

globular-toast wrote: post #88
joshuamorton wrote: post #73

Earlier quoted context omitted.

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

Ah yes... good old anecdotal evidence.

The org I'm in regularly publishes peer reviewed papers on engineering productivity (including on this particular subject!). It's far less anecdotal than a random talk by a random dude.

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

#97

Post by globular-toast »

joshuamorton wrote: post #96
globular-toast wrote: post #88

Earlier quoted context omitted.

Ah yes... good old anecdotal evidence.

The org I'm in regularly publishes peer reviewed papers on engineering productivity (including on this particular subject!). It's far less anecdotal than a random talk by a random dude.

Could you kindly link to one of those papers?

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

#98

Post by globular-toast »

marcusbuffett wrote: post #95
globular-toast wrote: post #68

Earlier quoted context omitted.

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

I have to really question how the study was conducted if only 1-2% of python errors were considered type errors. Even if the only type error you consider is None vs not None, you'd get more than that. Certainly those errors account for more than 1% of the errors I see in my own professional experience using Python. I'm curious what his reasoning was so I'll watch the talk, but there's something screwy there.

It's a good talk even if just to learn more about types. It's not even specifically about python.

The result might be surprising, but those are the most interesting results! I note that, so far, nobody has countered this with any evidence, only anecdotes and "surely not!"

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

#99

Post by zelphirkalt »

IshKebab wrote: post #93
zelphirkalt wrote: post #89

Earlier quoted context omitted.

GNU Guile can do that easily, as probably many other languages. The ecosystem is what makes people stick to Python, especially in areas like data science. Ecosystems are generally difficult to compete with, because they rely a lot on mind share. Mind share is a bit like gravity, in that clumps of matter will collect more matter. It takes very motivated people to implement solutions anew in another language, piece by…

GNU Guile is a weird Lisp variant. Nobody is switching from Python to that; be realistic. I do agree in some applications like data science / machine learning you could never get people to switch from Python because everyone uses it. But Python is also used for loads of other things, e.g. hacky build systems, web scraping, etc. that could easily switch.

It is actually more precisely a Scheme dialect. I used Racket for some time and then moved to Guile. I do not find it weird, having used other lispy languages before.

Guile has many useful tools, like OS level threads and also a fibers library, community projects, a good manual, albeit sometimes lacking a few examples, an active community and mailing list and more. Since it is a Scheme, it adheres to a Scheme standard, which specifies many things already. Then it implements many SRFIs, which also specify many things. I guess, that you name something that goes beyond the Scheme standard and beyond the SRFIs "weird".

Could you point out what more specifically you personally find weird about it?

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

#100

Post by short_sells_poo »

N1H1L wrote: post #79
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.…

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

Unfortunately mamba doesn't support working behind proxies (so it's a non-starter in most corporate environments) and it's anecdotal but I've had it fail and crash much more so than conda does. It is faster indeed, but there's the other aspect as another poster points out: there's now Mamba and Conda, so instead of having one standard, we now have two. Plus, mamba can't be used for creating and managing environments, so you still have to do 'coda env create ...' for example.
Post reply on HN