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

51–60 of 70 posts

Re: An Update on Pytype

#51

Post by rhaps0dy »

diggan wrote: post #13
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?

> Is there a good reason to avoid using Pyrefly? Wouldn't the other way around be easier for finding good tools? Figure out what matters to you, inspect if the project fulfills those needs and then go with it after making sure it works well for you. Regardless, a comparison between the two was posted to HN not too long time ago: https://news.ycombinator.com/item?id=44107655

> Wouldn't the other way around be easier for finding good tools?

I agree, and Pyrefly seemed good; I was just wondering why people don't mention it.

Thank you for the comparison thread and post, I've read it and found it useful! Thanks to that post I know ty has a "gradual typing" philosophy, which I disprefer.

Re: An Update on Pytype

#52

Post by steveklabnik »

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…

Rust supports s390x. https://doc.rust-lang.org/stable/rustc/platform-support/s390...

Re: An Update on Pytype

#53

Post by kingkilr »

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…

(pyca/cryptography dev here)

As Steve notes, Rust does support s390x. Even prior to shipping Rust code, we never tested or claimed to support s390x.

If there's genuine interest in more people supporting s390x in the open source world, folks will need to do the work to make it possible to build, test, and run CI on it. IBM recently contributed official PPC64le support to pyca/cryptography (by way of Github Actions runners so we could test and build in CI), and they've been responsive on weird platform issues we've hit (e.g., absl not support ppc64le on musl: https://github.com/pyca/infra/pull/710#issuecomment-31789057...). That level of commitment is what's really required to make a platform practical, treating "well, it's in C and every platform has a C compiler" as the sum total of support wasn't realistic.

Re: An Update on Pytype

#54

Post by zzzeek »

ipsum2 wrote: post #23
jdlyga wrote: post #19

I'm surprised Google still maintained their own solution for this for so long. The standard for statically type checking Python nowadays is mypy.

Mypy is far too slow to type check a codebase like Google's. That's why Facebook, Google, and Microsoft have/had their own solutions.

pylance and others are great for IDE type checking as you go along, but when you ship your code off to the CI it's best to stick to mypy for the full automated run, since mypy is in some aspects a bit of the "reference implementation" for python typing (meaning, it's a good choice as the common denominator the code you ship will have with other code it interacts with).

Re: An Update on Pytype

#55

Post by JoshTriplett »

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…

Note that Python, in 2022, adopted a "target tier policy" based on the one I wrote for Rust in 2019. (See https://peps.python.org/pep-0011/ , history at https://peps.python.org/pep-0011/#discussions ; original Rust version at https://doc.rust-lang.org/nightly/rustc/target-tier-policy.h... .)

It's important for projects to distinguish between "this might or might not work but it's nobody's job to support it" versus "people depend on this and will keep it working", so that people don't build on the former and think it's the latter. The latter requires active support and widespread user/developer interest, as well as comparable support from the upstream projects you build on (something shouldn't be tier 1 for you if it's tier 3 for one of your critical dependencies).

See https://news.ycombinator.com/item?id=43673439 for a comment from last time this came up.

s390x is currently supported by Rust, at tier 2, including host tools: https://doc.rust-lang.org/nightly/rustc/platform-support/s39... .

Re: An Update on Pytype

#56

Post by ipsum2 »

zzzeek wrote: post #54
ipsum2 wrote: post #23

Earlier quoted context omitted.

Mypy is far too slow to type check a codebase like Google's. That's why Facebook, Google, and Microsoft have/had their own solutions.

pylance and others are great for IDE type checking as you go along, but when you ship your code off to the CI it's best to stick to mypy for the full automated run, since mypy is in some aspects a bit of the "reference implementation" for python typing (meaning, it's a good choice as the common denominator the code you ship will have with other code it interacts with).

Ideally yes, but there's conflicts between the type checkers.

Re: An Update on Pytype

#57

Post by LtWorf »

vovavili wrote: post #38
LtWorf wrote: post #6

Earlier quoted context omitted.

I'm personally just staying away from startups anywhere in my dependencies.

The cost of your dogmatic preference is your Python experience being more miserable than it should be. Astral's ruff and uv are widely adopted for a good reason, and there is no reason to think that ty will come any different.

There is a reason and a potential much bigger cost I'm avoiding, that you are conveniently ignoring.

Re: An Update on Pytype

#58

Post by pjmlp »

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…

Visual C++ toolchain is rather easy to install, the issue is briging other OS expectations to Windows, likewise the other way around.

However I fully agree with you, the tooling for a given language should be written in the language itself, and it is an ecosystem failure when it doesn't happen.

I also feel that this trend, as usual, is people building their portfolio in the current trendy languages.

Re: An Update on Pytype

#59

Post by instig007 »

vovavili wrote: post #40
instig007 wrote: post #31

Scala 3: exists, https://docs.scala-lang.org/scala3/book/scala-features.html Developers: mypy, pyright, pyrefly, ty, pypy, nogil, faster-python, sub-interpreters, free-threading, asyncio, ...

This would have been a fair point had Scala 3 supported Python's packages and was compatible with Python's tooling. At the very least until Mojo is mature and open-sourced, there are simply no alternatives to pouring time and effort into making Python a better language.

> This would have been a fair point had Scala 3 supported Python's packages

It supports the entirety of JDK-compatible packages and FFI/JNI bindings, which is a fair point of the comparison. Not sure why you have to frame it around the idea of necessarily having to improve Python, as the JDK infra and tooling have been around for ages, available to be picked by the devs.

Post reply on HN