10 ms·
"We're building a new static type checker for Python"
- deneb150 2y agoI've been waiting for this to happen, very excited to start using it.
- shlomo_z 2y agoI am really excited. Ruff is amazing, uv literally fixed all the python packaging issues we have, and now a type checker!! Can't wait to see it!
- josh-sematic 2y agoTL;DR on the status: they've been working on it for a while, but it's not yet ready for playing around with.
- esafak 2y agoThis is all very well but how are going to make money? They have taken VC investments.
- _diyar 2y agoIf they open source it, who cares? Obviously I would like them to continue maintaining their stuff, and I am sure they are imaginative enough to find some source of income.
- esafak 2y agoIt must be nice to receive VC funding without knowing how you are going to repay it!
- maccard 2y agoHonest question - have you worked with VC’s much? That’s pretty much the MO. Get a snippet of an idea that has the potential to scale to unicorn levels, make sure you have a super coarse idea of how to monetise it, and then shoot and see how far you get.
- barnabee 2y agoVC funded companies (almost[0]) never repay it. They only try to create enough value that the VC can one day sell their stake for more than they paid for it. The key is convincing the VC not that that is particularly likely, but that if it happens there's a chance it'll be a lot more than they paid for it. [0] occasionally a company gives money back to investors when it fails
- simonw 2y agoThere's a bit of an answer to that from Charlie Marsh here: https://hachyderm.io/@charliermarsh/113103579845931079 https://hachyderm.io/@charliermarsh/113103579845931079 > What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today. > An example of what this might look like (we may not do this, but it's helpful to have a concrete example of the strategy) would be something like an enterprise-focused private package registry. A lot of big companies use uv. We spend time talking to them. They all spend money on private package registries, and have issues with them. We could build a private registry that integrates well with uv, and sell it to those companies. [...]
- giancarlostoro 2y agoHonestly, they should do that, it would force their competitors to actually improve their own, and if they don't well, there you go, really great funding your way.
- TheTaytay 2y agoAh, that makes a lot of sense. Sounds like they have patient investors. They are doing amazing work.
- claytonjy 2y agothe packaging one is an odd example because it’s hard to imagine a company that both needs an enterprise packaging solution external to their cloud provider, and is python only i have a similar concern for the Pydantic folks commercializing via observability platform; how big is the market for python-only observability? i think both cos will either look for money elsewhere, or find themselves having to deal with at least a few other language ecosystems. Even python+typescript would 10x the TAM or more
- physicsguy 2y agoI'm not sure that business model exists personally but good luck to them. It's trivial to spin up an index on AWS or Azure. Usually for a company it's hard for minions dealing with this stuff to get approval to spend money on a new supplier, but easy to set up something with your existing cloud provider.
- benatkin 2y agoA Microsoft acquisition? Could help them to keep their open source trickery going. https://ghuntley.com/fracture/ https://ghuntley.com/fracture/
- joshdavham 2y agoThese questions are often hard to answer for people unfamiliar with how VC works, but mostly because VC is not intuitive from a 'normal business' perspective. Essentially, VC's know very that what they're funding is risky and may go completely caput. However the VC model explicitly aims to fund companies that have the potential of becoming huge and becoming very profitable. Both the founders and VC's behind Astral are not stupid, they know that it could fail or only have moderate success... However, if they succeed in building the next generation go-to ecosystem for python development (which is arguably the world's most popular programming language), we could imagine a future where they spin off some product and it does incredibly well!
- robertlagrant 2y agoIt's not that that future's unimaginable. It's more that it would be nice to have an easy path to knowing how these tools will be funded. They will suck time and effort out of the ecosystem of Python tools, which is fine, except it's not fine if they vanish or decay in X years' time because of funding issues. I don't know the solution, and I really think these tools look about as great as tools can look, so I'm very keen to use them. I would just like some way to know that they'll be supported for 10 years at least.
- jasonpeacock 2y agoIt's hard to find details...apparently it's code named "red knot" (or "red_knot"). Here's the github issues filter linked in the screenshot: https://github.com/astral-sh/ruff/labels/red-knot https://github.com/astral-sh/ruff/labels/red-knot And the best answer/description of what the type checker will be: https://github.com/astral-sh/ruff/discussions/15149 https://github.com/astral-sh/ruff/discussions/15149
- smpretzer 2y agoAnother useful issue filter: https://github.com/astral-sh/ruff/milestone/20 https://github.com/astral-sh/ruff/milestone/20
- SandmanDP 2y ago> apparently it's code named "red knot" (or "red_knot") Missed opportunity to call it typy in my opinion
- kalb_almas 2y agoIs anyone going to tell them how bad that name is? Especially considering their other project is called ruff...
- hooverd 2y agoVery cool. I wonder where the codename comes from?
- zanie 2y agoIt's a joke about how Charlie didn't know Ruff was a bird. https://en.wikipedia.org/wiki/Red_knot https://en.wikipedia.org/wiki/Red_knot
- tylerhillery 2y agoMy vote for the name was rype but it lost
- joshdavham 2y agoThis is exciting! I'd love to be able to use something other than mypy, especially if it's way faster!
- IshKebab 2y agoPyright is already 100x better than Mypy. Honestly there's no good reason to use Mypy. It isn't much faster though so hopefully this will fix that.
- westurner 2y agoCould it please also do runtime type checking? (PyContracts and iContract do runtime type checking, but it's not very performant.) That MyPy isn't usable at runtime causes lots of re-work.
- StackTopherFlow 2y agoHave you tried beartype? It's worked well for me and has the least overhead of any other runtime type checker. https://github.com/beartype/beartype https://github.com/beartype/beartype
- N1H1L 2y agoI think TypeGuard (https://github.com/agronholm/typeguard https://github.com/agronholm/typeguard) also does runtime type checking. I use beartype BTW.
- westurner 2y agopycontracts: https://github.com/AlexandruBurlacu/pycontracts https://github.com/AlexandruBurlacu/pycontracts icontract: https://github.com/Parquery/icontract https://github.com/Parquery/icontract The DbC Design-by-Contract patterns supported by icontract probably have code quality returns beyond saving work. Safety critical coding guidelines specify that there must be runtime type and value checks at the top of every function.
- drcongo 2y agoI use TypeGuard too, but only in local dev and pytest runs. I find it really useful so I'm now intrigued to try Beartype too. I found the readme on GitHub confusing at a glance though, I need decorators to type check something?
- monlockandkey 2y agoThey just need to add a task runner feature (already being worked on) and the one tool to rule them all would be complete. Package manager, linter, formatter, type checker, task runner. Am I missing something? Maybe a build tool? https://github.com/astral-sh/uv/issues/5903 https://github.com/astral-sh/uv/issues/5903
- roywashere 2y agoI still hope they build a Heroku alternative. I think their work on uv might be some of the building blocks they would need?
- monlockandkey 2y agoThat sounds plausible. Vercel equivalent for the Python ecosystem. UV deploy
- CapeTheory 2y agoWhen it comes time to write Python 4, please just let these guys handle it.
- g_delgado14 2y agolet him coooook
- binary132 2y ago“We’re building a new high-speed seatbelt system for covered wagons”
- globular-toast 2y agoIs it going to be like mypy or pyright? Will it include an LSP server? Pyright seems more focused on the LSP server side and doesn't seem as complete as mypy as a type checker.
- dcreager 2y agoThe aim is to support both incremental ongoing type checking via something like an LSP server, and also batch type checking for use in e.g. CI. > The entire system is designed to be highly incremental so that it can eventually power a language server (e.g., only re-analyze affected files on code change). https://bsky.app/profile/crmarsh.com/post/3lgvhzeawuc26 https://bsky.app/profile/crmarsh.com/post/3lgvhzeawuc26
- mwt 2y agokinda mixed on this - why not just contribute to the community tool? - there's already a major split in Python type-checking tools, if there's a third that doesn't agree with either of them it'll be a mess for projects to deal with - astral has been hiring like mad recently and has yet to communicate that they can actually make money ($5 million doesn't last forever) - does it actually exist? is this currently a closed-source codebase, or is "we're building" future tense?
- dcreager 2y ago> does it actually exist? is this currently a closed-source codebase, or is "we're building" future tense? From the thread: > We haven't publicized it to-date, but all of this work has been happening in the open, in the Ruff repository.
- shlomo_z 2y ago- They usually so a pretty good job adhering to standards - re: the money: https://news.ycombinator.com/item?id=42869358 https://news.ycombinator.com/item?id=42869358
- mwt 2y agoUnfortunately that doesn't answer the question
- zem 2y ago
- theLiminator 2y agoVery excited for this, looks like it's built on top of pretty solid technical foundations (iirc, it uses salsa from rust for incremental type checking). I've found mypy pretty terrible. Pyright is okay (but requires node). Ruff truly can become one tool to rule them all.
- dcreager 2y ago> it uses salsa from rust for incremental type checking This is true! We're also contributing salsa features upstream where we can, e.g. https://github.com/salsa-rs/salsa/pull/603 https://github.com/salsa-rs/salsa/pull/603
- IshKebab 2y agoI agree, Mypy is awful. Pyright is very good but also quite slow, and its Node requirement is awkward in some cases (e.g. pre-commit). A fast Rust based type checker would be amazing!
- Noumenon72 2y agoI'd appreciate knowing what's wrong with MyPy that this project will fix. Check time? Bad rules? Lack of features?
- tcdent 2y agoyeah, 'awful' is just the OP being dramatic, though I am looking forward to Astral's contribution
- theLiminator 2y agoI think that https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com... actually covers the majority of my gripes with mypy, the main issues I encounter with mypy are due to its lack of precision. It produces a lot of false positives for code that is well-typed that pyright can handle. Also the lack of type inference and lack of type checking for unannotated code (by default) is kinda painful. Mypy in general makes certain patterns which are pythonic not typecheck whilst pyright is a lot less painful in that regard. I've personally found that dealing with mypy has been more noisy and painful than using pyright and leads to a lot of users/other devs just ignoring typing altogether. I think that type checking has to closely match the semantics of the language and if there's a gap, it will often push users to do the easy thing, which is just ignoring checks.
- dcreager 2y agoBluesky cross-post for those who don't want to read the thread on X: https://bsky.app/profile/crmarsh.com/post/3lgvhzdfrps26 https://bsky.app/profile/crmarsh.com/post/3lgvhzdfrps26
- timeon 2y agoAs someone without X or Bluesky, this link shows whole thread while X does not.
- uneekname 2y agoYeah, this is a better link. Can we swap it out?
- StackTopherFlow 2y agoDoing the lord's work
- mixmastamyk 2y agoI don't care about politics, but don't load javascript from just anyone. Not to read hundreds of characters, surely. Neither site works without it.
- sureglymop 2y agohttps://nitter.poast.org/charliermarsh/status/1884651482009477368 https://nitter.poast.org/charliermarsh/status/18846514820094...
- zzzeek 2y agoyou care extremely deeply about politics such that they align so closely with your personal comfort that you need not have to notice it
- robertlagrant 2y agoSome people actually don't care, other than getting mildly irritated by the people who think politics is everything, and are so captured they can't imagine any other way of thinking.
- agumonkey 2y agoApplaud the effort, but it's weird seeing python (and es6) living more and more on top of native static analyzers/transpilers .. at which point will they become a frontend syntax for ocaml or julia ? :p
- snovymgodym 2y ago> at which point will they become a frontend syntax for ocaml or julia ? At no point. What probably will happen is that both the JS and the Python reference implementations will have first class support for type systems which will allow them to generate optimized native code for the typed sections of your code while keeping the untyped sections as bytecode or as higher level compiled code (i.e. a bunch of runtime function calls dealing with tagged union objects).
- zem 2y agoas someone working in this space, the idea is that most python code is implicitly statically typed anyway, in that your functions are only ever meant to be called with specific types for their arguments, and only return objects of a specific type. all that static type analysis does is to make that explicit via type annotations, and then verify that you have indeed used types correctly in your code. static compilers then say "well, if we know the static types of everything in this function, we can compile it to more efficient code, skipping all the dynamic lookups and runtime type checks and dispatching". typically there is an escape hatch that will fall back to regular python behaviour if your code is indeed dynamic (e.g. reflecting on a database schema to generate models at runtime), but losing the benefits of static analysis and optimisation. if you would like to read more on the topic the keyword is "gradual typing"; in particular you might be interested in looking up stanza, a language designed around gradual types from the outset rather than retrofitting them on top of a dynamically typed language.
- agumonkey 2y agothis https://lbstanza.org/index.html https://lbstanza.org/index.html ? what are places to discuss gradual typing these days ? I stopped looking a few years ago (after clojure and scheme started projects on that topic)
- intalentive 2y agoI would use a statically-typed Python that you can compile into a binary for better performance. Step 1: Develop fast in regular Python. Step 2: Add type annotations and build.
- alias301 2y agoYou're in luck! https://github.com/mypyc/mypyc https://github.com/mypyc/mypyc
- Havoc 2y agoWow those are pretty chunky improvements over vanilla
- wk_end 2y agoAFAICT this is dead (no updates in four years) and "alpha software...only recommended for production use cases with careful testing, and if you are willing to contribute fixes or to work around issues you will encounter." Unfortunate, because it's pretty cool.
- fuzztester 2y agoMojo from Modular? I've not checked it out enough yet, and it's early days for it anyway. Just saying it may be worth keeping an eye on. I've seen some videos of Chris Lattner talking about it. https://www.modular.com/mojo https://www.modular.com/mojo https://hn.algolia.com/?q=mojo https://hn.algolia.com/?q=mojo
- ehutch79 2y agoMy big question is django support. Django has a lot of magic that makes type checking more difficult than it should be. I'm not really expecting anything, even just the speed bump will be nice.
- claytonjy 2y agois Django working towards using native types instead of all they stuff they invented before type hints existed?
- rtpg 2y agoI am not part of the DSF or anything but I can say with a good amount of confidence that the answer to this is “No”. Moving to a Pydantic-style model would be a whole different ballgame. Hell of a lot of work, and meanwhile we can’t even really get to “let’s have type hints in some of the Django infernals”. But! I do think someone who wants to have fun could try to build a type hint based Model subclass as a third party lib! There’s a looooot of stuff to resolve in that world but for any proposal like that the general vibe is “prove the feasibility with a third party package first”.
- c-fe 2y agoI think there is potential for a new python web framework with batteries included (like django) but using newer paradigms (typing, …). Fastapi itself is a nice concept but its a bit of a mess (the main author just keeps closing bug issues and adds somewhat useless things (just check the git commit log)), and also it requires db tooling (sqlalchemy) and other things
- screye 2y agoAt the risk of sounding like a fanatic, I bet it will be great. Everything Astral have put out has been a step improvement to my python dev flow. Until they disappoint me, I'm staying on this hype train.
- kittikitti 2y agoI started learning Python when it was barely at version 1 precisely because there was no real static type checking. If I wanted that, I would just write the program in C or its variants. I wasn't excited about type hints because developers became super judgy if there weren't any. I just want to know why you're using Python if you want stronger typing and feel the need to change the entire language instead of using another one yourself.
- jes5199 2y agoC types are almost entirely unlike modern type-checking
- jaredklewis 2y agoProbably because a lot of programmers don't get to choose the language they are using. They have a job developing some existing app that is already written in Python, but they wish it wasn't Python. They don't have an option to rewrite the whole codebase in Rust or whatever, so the best they can do is advocate for Python to evolve to be more like languages they do like.
- gt0 2y agoI think this is exactly it. My gut instinct is just "Why the obsession with adding static types to Python, just use a language that already has good static types". As you say though, not everybody gets to choose their language, and I certainly wouldn't choose Python if I could possibly help it, so if we can add good static types to Python, it's still not a great language, but it's much improved by static types.
- baq 2y agoI’m a Pythonista of two decades who is working with typescript (on the backend) for the past two years and absolutely loving it. I don’t like the js part, but it doesn’t matter too much except when you’re working with numbers, which are a bit insane. If anyone built a typescript layer on top of Python, I’d cheer that effort. If that new thing from the article will be that, I’m stoked.
- nimish 2y agoastral doing what the endless layers of admin/people in the PSF can't: solve actual problems python devs face
- robertlagrant 2y agoThis is my feeling as well. I really care far more about good tools than whatever it is the PSF does. Perhaps it does good things that I don't know about, but it's really hard to spot.
- nimish 2y agoThey basically spend their time endlessly debating trivialities and preventing improve to the libraries and language
- aldanor 2y agoFinal piece of the puzzle will be one LSP to rule them all, unifying all previous work - aka python-analyzer.
- jokoon 2y agoI wonder why making those sort of tools is so difficult
- egeres 2y agoAstral has consistently surprised the python community with amazing tooling. It was a matter of time before they jumped into type checking. I think ruff and uv were good first MVPs for a small company with a highly talented team. I can't help but wonder if someday they'll attempt to build their own Python interpreter in Rust, or if that's overkill.
- sureglymop 2y agohttps://nitter.poast.org/charliermarsh/status/1884651482009477368 https://nitter.poast.org/charliermarsh/status/18846514820094...
- deleted 2y ago[deleted]
- exabrial 2y agoWouldn't it make more sense to make a statically typed language? Like Crystal is to Ruby?
- Too 2y agoNew language means throwing out the ecosystem, which is one of pythons biggest strength. There are and have been multiple attempts on compiling python, most recent promising shot is Mojo aiming for library compatibility.
- rosiesophia10 2y ago[dead]
- bmitc 2y agoIt's interesting to me that one of the most popular, if not the most popular, language in the world and one that is decades old has tooling that is constantly evolving and being reinvented and now in another language than itself. Contrast this with Rust and Elixir which have developed superior tooling in just a decade or so. I just started with real Python development in the past year and have already switched basic tooling!
- mtndew4brkfst 2y agoElixir is an unintuitive inclusion for praise on this topic, to me. We have dialyzer, which is very polarizing and frequently maligned, and somewhere between 2.0 and 3.5 partial implementations of LSP depending on how you're counting. It's been radio silence ever since the last public blog post announcing the formation of the new LSP team/project and the incumbents still ship new code periodically, so I have no idea where that stands. None of them hold a candle to r-a in their current forms. Credo is pretty solid, and Adobe's styler is neat but I wouldnt blame anyone for sticking to vanilla `mix format`. ExUnit is also fine. I'll never touch Ash or Igniter, as they don't speak to my personal or professional values. I can't speak to the type-system stuff in 1.18, as I have a bunch of "code-complete" dependencies that won't build without compiler warnings. Outside of that blind spot I consider Elixir to be in an ongoing tooling slump, personally. Certainly when compared to more innovative and populous ecosystems.
- borromakot 2y agoAuthor of Ash/Igniter here, curious how it doesn't speak to your personal values. Are we doing something that you find problematic at a non-technical level?
- wood-porch 2y agoGood riddance! I’m optimistic that these guys will transform the typing landscape, which, let’s be honest, has room for improvement. I find mypy abysmal to use, bug-ridden with weird defaults, and extremely painful to add to an existing codebase
- LorenzoGood 2y agohttps://xkcd.com/927/ https://xkcd.com/927/