It’s like when we hit a new month the quota of “talk about Rust” credits is renewed.
Say what you want, Astral ships impressively fast and their stuff works well. Python has been looking for better tooling for a long time.
Ty: A fast Python type checker and language server
151–160 of 296 posts
Re: Ty: A fast Python type checker and language server
#152I gave away the “ty” project name on pypi to Astral a week or so ago. I wanted to use it for a joke a few years ago but this is a much better use for a two letter project name. They agreed to make a donation to the PSF to demonstrate their gratefulness.
ty--thank you
Re: Ty: A fast Python type checker and language server
#153I gave away the “ty” project name on pypi to Astral a week or so ago. I wanted to use it for a joke a few years ago but this is a much better use for a two letter project name. They agreed to make a donation to the PSF to demonstrate their gratefulness.
[deleted]
Re: Ty: A fast Python type checker and language server
#154[dead]
Re: Ty: A fast Python type checker and language server
#155Earlier quoted context omitted.
> Pre-alpha are much better as .dev releases. No, they are correctly using semantic versioning to indicate pre-alpha releases. https://github.com/astral-sh/ty/releases https://semver.org/
Python doesn’t use plain semver: https://peps.python.org/pep-0440/
The reference Python implementation, written in C, doesn't use semver. But other projects in the Python ecosystem are generally assumed to unless stated otherwise. For example, Setuptools does (but not pip: https://pip.pypa.io/en/stable/development/release-process/).
Re: Ty: A fast Python type checker and language server
#156prior to astral appearing, python's tooling has been beyond terrible, compared to say, Java's astral have now replaced the awful pip with the fantastic uv various awful linters with with the fantastic ruff and now hopefully replacing the terrible type checkers (e.g. mypy) with a good one! I hope they have the pypi backend on their list too, my kingdom for Maven Central in python!
What issues do you have with the PyPI backend?
Re: Ty: A fast Python type checker and language server
#157Earlier quoted context omitted.
If they're making our lives better, perhaps the question is whether we've figured out how to pay them yet.
From my experience it's VERY rare for people to pay for anything unless they're forced, I do the same thing even though I'm very aware of the need for compensating creators. Talk is cheap, and people talk a lot about supporting projects. Maybe if we could make some kind of statistics over the number of projects that were abandoned because maintainers didn't feel like working and dealing with random people for free an…
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 their products possible, or we all just go on strike for that week. Or... something. I'm sure somebody has a better idea than mine, lets get creative.
Re: Ty: A fast Python type checker and language server
#158The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods. I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck th…
> 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…
mypy is compiled using mypyc. It does not run as Python code.
Re: Ty: A fast Python type checker and language server
#159Earlier quoted context omitted.
Even after all the praise, I'd say they're underrated. Modular.ai raised $100 million to solve tangentially similar problems with python. Astral has already had a much larger impact, while providing better integration with less than 10% of that money.
disagree. modular has a different focus, to turn python into a systems language. you could even say that astral and modular focus on two extreme ends of the developer experience spectrum - just making python tooling faster, vs making python-ish code faster.
To be clear, I wasn't dunking on Modular. I meant it more as praise for what Astral has achieved. Lattner is a veteran and Mojo seems to be coming along at a good pace. Mojo is admittedly more of a Rust-competitor. Couldn't think of other contemporary "we are trying fix python's problems" companies. So went for the low hanging fruit.
Either way, Python's irritants are the 'stick' that motivates devs to try alternatives. Astral is patching python's problems at lightning speed. Soon, there may not be enough incentive left to migrate off python. I'm assuming Mojo's target customer is an application dev who uses python and not a seasoned system dev looking for a more aesthetic language.
fwiw, I hope Mojo succeeds.
Re: Ty: A fast Python type checker and language server
#160The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods. I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck th…
> 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…
Python is slow for some CPU-intensive operations.
There are some extremely CPU-intensive low-level operations that you can easily write in C and expose as a Python API, like what Numpy and Pandas do. You can then write really efficient algorithms in pure Python. As long as those low-level operations are fast, those Python-only algorithms will also be fast.
I don't think this is necessarily "cheating" or "just calling disguised C functions." As an example, you can write an efficient linear regression algorithm with Numpy, even though there's nothing in Numpy that supports linear regression specifically, it's just one of the ways a Python programmer can arrange Numpy's low-level primitives. If you invent some new numerical algorithm to solve some esoteric problem in chemistry, you may be able to implement it efficiently in Python too, even if you're literally the first person ever writing it in any language.
The actual problem is that it's hard for people to get an intuition of which Python operations can be made fast and which can't, AST and file manipulation are sadly in the latter group.