I am literally checking HackerNews while I wait for mypy to finish running, so I am excited to hear a faster type checker is on the way! Hope the error messages are also helpful.
Ty: A fast Python type checker and language server
181–190 of 296 posts
Re: Ty: A fast Python type checker and language server
#182:wave: Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :) Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready. Sta…
What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would be if the type checker worked across the broader ecosystem of common Python packages. For example, as my recent struggles showed, SQLAlchemy breaks `pyright` in all kinds of ways. Compared with how other 'dynamic' ORMs like Prisma interact with types, it's ju…
My experience is this is nearly impossible, the solution is new packages written after typing was introduced.
I don’t know about SQLAlchemy, but for libraries like pandas I just don’t see how it can be done, and so people are actively replacing them with modern typed alternatives
Re: Ty: A fast Python type checker and language server
#183Earlier quoted context omitted.
That has been my experience as well. I consider it a bug. I'm not proposing that we all just try harder to be altruistic, but rather that we craft some institution for rewarding people who have solved problems for many without encumbering those solutions with a monetization scheme. Make like, a week long "holiday" where you either verify that your company has made an adequate donation to the OSS maintainers that make…
> I'm not proposing that we all just try harder to be altruistic, but rather that we craft some institution for rewarding people who have solved problems for many without encumbering those solutions with a monetization scheme. > I'm sure somebody has a better idea than mine, lets get creative. Every creative scheme I've seen someone try to come up with fails to do what charging money for a product can. Charge money f…
That's fine for software that can still scratch the itch after it has been turned into a product, but I think there's a lot of unexplored space outside that category.
There's also a bunch of cases where adding tiers and payment flows blows the complexity budget and now what used to be a good idea is no longer worth it.
Re: Ty: A fast Python type checker and language server
#184:wave: Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :) Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready. Sta…
What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would be if the type checker worked across the broader ecosystem of common Python packages. For example, as my recent struggles showed, SQLAlchemy breaks `pyright` in all kinds of ways. Compared with how other 'dynamic' ORMs like Prisma interact with types, it's ju…
You mean Python is not a language for production applications ?
Re: Ty: A fast Python type checker and language server
#185Earlier quoted context omitted.
At least for the moment, we aren't planning on a plugin architecture. We do recognize that there are some popular libraries and code patterns that aren't easily (or at all) typeable with the current state of the typing spec. We feel it would be more useful to help drive changes to the typing spec where we can, so that other type checkers can also benefit; and/or implement workarounds for the most popular libraries di…
Helping improve the spec and all is great, but being 100% honest, as a user, I would rather have a type checker I can bend to my needs. As you said, some code patterns in a dynamic language like Python are difficult, or even impossible, to type-check without custom code. Type checkers are becoming more popular than ever, and this implicitly means that these code patterns are are going to be discouraged. On one hand,…
Can you either give some additional details on the code patterns you’re talking about, or link to some ‘typical’ examples? I do appreciate the flexibility of being able to just write code and not particularly be overly sensitive to jumping through typing hoops, but I can’t think of any place I’ve actually used algorithms or specific code patterns that rely on untyped-ness to actually work at run time. I’d be very interested in trying to work through what is actually required to consider these code patterns as well-typed.
Re: Ty: A fast Python type checker and language server
#186Earlier quoted context omitted.
Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast. https://github.com/microsoft/pyright
I tested it side-by-side on my ~100Kloc codebase. Ty: 2.5 seconds, 1599 diagnostics, almost all of which are false positives Pyright: 13.6 seconds, 10 errors, all of which are actually real errors There's plenty of potential here, but Ty's type inference is just not as sophisticated as Pyright's at this time. That's not surprising given it hasn't even been released yet. Whether Ty will still perform so much faster on…
Compilation / type checking depends on a lot of trees of typed data, and operating on those tree nodes. That's something where a statically typed language with custom data structures that allows for optimised representations makes a big difference, and where a lot of the fancy optimisations in v8 don't work so well.
There is a reason Typescript moved to a typed language.
Re: Ty: A fast Python type checker and language server
#187Earlier quoted context omitted.
> The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. Or in this case, writing it in Rust... mypy is written in Python. People have forgotten that Python is really, really slow for CPU-intensive operations. Python's performance may not matter when you're writing web service code and the bottlenecks are database I/O and network calls, but for a tool that's…
> such as claiming `datetime.UTC` doesn't exist) This is a known issue — we're currently defaulting to a conservative Python version, and `datetime.UTC` really doesn't exist until Python 3.11! https://docs.python.org/3/library/datetime.html#datetime.UTC We will probably change the default to "most recent supported Python version", but as mentioned elsewhere, this is very early and we're still working out these kinds…
You should be doing this dynamically based on the version of python you are running against, so that you don't have to hardcode or make such "conservative" choices by hand.
Re: Ty: A fast Python type checker and language server
#188:wave: Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :) Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready. Sta…
What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would be if the type checker worked across the broader ecosystem of common Python packages. For example, as my recent struggles showed, SQLAlchemy breaks `pyright` in all kinds of ways. Compared with how other 'dynamic' ORMs like Prisma interact with types, it's ju…
Have you tried SQLModel?
Re: Ty: A fast Python type checker and language server
#189Earlier quoted context omitted.
What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would be if the type checker worked across the broader ecosystem of common Python packages. For example, as my recent struggles showed, SQLAlchemy breaks `pyright` in all kinds of ways. Compared with how other 'dynamic' ORMs like Prisma interact with types, it's ju…
My experience is this is nearly impossible, the solution is new packages written after typing was introduced. I don’t know about SQLAlchemy, but for libraries like pandas I just don’t see how it can be done, and so people are actively replacing them with modern typed alternatives
Ha. I just finished a huge rewrite at work from sync SQLAlchemy to async SQLAlchemy, because the async version uses a totally different API (core queries) to sync. So this implies if I want type checking I need to use a different ORM and start again?
I love how Python makes me so much faster due to its dynamic nature! Move fast, break things!
Re: Ty: A fast Python type checker and language server
#190Have these guys figured out how to make money yet?
They might pivot to some enterprise value added services. Probably around SAST - think sonarqube.