Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Update on Pytype

github.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: An Update on Pytype

#41

Post by delduca »

silentsea90 wrote: post #14
delduca wrote: post #9

Another abandoned project from Google? Not surprised. Never trust on Google.

Pytype is used heavily inside Google so they bear the penalty likely more than you. Besides, py typing libraries is a dynamically changing landscape so it isn't anything out of the norm. Not everything is an abandoned project, and if anything Google abandons some projects well after the winners and losers are apparent eg Tensorflow.

You have no ideia how many projects from them I used to use and from day to night they drop the development.

Google sucks.

Re: An Update on Pytype

#42

Post by librasteve »

zem wrote: post #28

ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…

why not just go with a language that has gradual typing built in - eg raku

Re: An Update on Pytype

#43

Post by zem »

librasteve wrote: post #42
zem wrote: post #28

ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…

why not just go with a language that has gradual typing built in - eg raku

because there is a ton of existing python code that people find a lot of value in, and that no one wants to abandon. the return on investment for making python better is insanely higher than that on porting hundreds of millions of lines of code to another language.

Re: An Update on Pytype

#45

Post by xenophonf »

zem wrote: post #28

ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…

> I have recently jumped onto the "write python tooling in rust" bandwagon

I know Go and Rust are the belles du jour, but this kind of thing really hampers integrators' ability to support platforms other than x86-64 and armv8. In my particular case, it results in me being unable to build software that depends on pyca/cryptography on platforms like s390x, which makes me sad. It also makes development environment management, including CI/CD pipeline maintenance, that much more complicated. It was already bad enough when I was trying to compile binary distributions on Windows, and that was just with the Visual C++ toolchain mess that is the Microsoft development experience.

Re: An Update on Pytype

#46

Post by zem »

xenophonf wrote: post #45
zem wrote: post #28

ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…

> I have recently jumped onto the "write python tooling in rust" bandwagon I know Go and Rust are the belles du jour, but this kind of thing really hampers integrators' ability to support platforms other than x86-64 and armv8. In my particular case, it results in me being unable to build software that depends on pyca/cryptography on platforms like s390x, which makes me sad. It also makes development environment manag…

I can sympathise with that, but to argue a bit for the other side, these tools are mainly intended to run on the developer's machine or in the CI pipeline. in both cases they overwhelmingly use architectures that rust supports, and in the case of CI surely it's easier to deploy a single rust binary than a python binary and all its library dependencies.

I used to be very much in the "write your language tools in the language and the community will contribute" camp, but astral has really shown what a big difference pure speed can make, and I now have more of a "write tools in rust and ideally make sure they also expose libraries that you can call from python" mindset.

Re: An Update on Pytype

#47

Post by rhaps0dy »

veber-alex wrote: post #15
rhaps0dy wrote: post #11

Earlier quoted context omitted.

I've heard of `ty` too but recently I learned about Pyrefly, which is not in pre-production alpha, and is also Rust: https://pyrefly.org/ Is there a good reason to avoid using Pyrefly?

https://github.com/facebook/pyrefly/releases Pyrefly v0.29.0 Status : ALPHA

Hah, I stand corrected. In my defense, Ty make it a lot more obvious and ominous on their github (https://github.com/astral-sh/ty):

> /!\ Warning

> ty is in preview and is not ready for production use.

> We're working hard to make ty stable and feature-complete, but until then, expect to encounter bugs, missing features, and fatal errors.

Re: An Update on Pytype

#48

Post by rhaps0dy »

denis- wrote: post #34
jolux wrote: post #12

Earlier quoted context omitted.

I believe Pyrefly is stricter, so it may be a better choice for new projects but harder to integrate into existing ones without type-checking.

I have a medium-sized codebase that is all green when running mypy with the strictest configuration possible. Pyrefly spits put around 200 errors for the same codebase. Most errors are related to SQLAlchemy.

I mean, sqlalchemy until very recently needed a mypy plugin to type correctly (https://docs.sqlalchemy.org/en/20/orm/extensions/mypy.html), which was just deprecated in 2.0.0.

Perhaps you should do the upgrade (https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...) and try again?

Re: An Update on Pytype

#49

Post by endgame »

xenophonf wrote: post #45
zem wrote: post #28

ex-pytype dev here - we knew this was coming and it's definitely the right thing to do, but it's still a little sad to see the end of an era. in particular, pytype's ability to do flow-based analysis across function boundaries (type checking calls to unannotated functions by symbolically executing the function body with the types of the call arguments) has not been implemented by any of the other checkers (again for…

> I have recently jumped onto the "write python tooling in rust" bandwagon I know Go and Rust are the belles du jour, but this kind of thing really hampers integrators' ability to support platforms other than x86-64 and armv8. In my particular case, it results in me being unable to build software that depends on pyca/cryptography on platforms like s390x, which makes me sad. It also makes development environment manag…

On top of all this, pretty much everything depends on Python (even glibc's build system depends on it now), and Rust is relatively hard to bootstrap. So bootstrapping a usable Python on glibc could one day involve bootstrapping all the way up to Rust on musl (including e.g. llvm) just to get Python just to build the final system's libc.

That doesn't feel great to me.

Re: An Update on Pytype

#50

Post by zem »

endgame wrote: post #49
xenophonf wrote: post #45

Earlier quoted context omitted.

> I have recently jumped onto the "write python tooling in rust" bandwagon I know Go and Rust are the belles du jour, but this kind of thing really hampers integrators' ability to support platforms other than x86-64 and armv8. In my particular case, it results in me being unable to build software that depends on pyca/cryptography on platforms like s390x, which makes me sad. It also makes development environment manag…

On top of all this, pretty much everything depends on Python (even glibc's build system depends on it now), and Rust is relatively hard to bootstrap. So bootstrapping a usable Python on glibc could one day involve bootstrapping all the way up to Rust on musl (including e.g. llvm) just to get Python just to build the final system's libc. That doesn't feel great to me.

please note that I am not talking about introducing rust into the python interpreter (where, I agree, bootstrapping concerns would make the gain in code maintainability not really worth it), but in writing developer tools that work with python in rust or a mix of rust and python rather than in pure python. these are tools that run on the developer's machine or on test/ci servers, not in the target environment.
Post reply on HN