[HN Gopher] "We're building a new static type checker for Python"
___________________________________________________________________
"We're building a new static type checker for Python"
Author : shlomo_z
Score : 207 points
Date : 2025-01-29 17:56 UTC (5 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| shlomo_z wrote:
| I 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!
| deneb150 wrote:
| I've been waiting for this to happen, very excited to start using
| it.
| josh-sematic wrote:
| TL;DR on the status: they've been working on it for a while, but
| it's not yet ready for playing around with.
| esafak wrote:
| This is all very well but how are going to make money? They have
| taken VC investments.
| _diyar wrote:
| If 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 wrote:
| It must be nice to receive VC funding without knowing how you
| are going to repay it!
| maccard wrote:
| Honest 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 wrote:
| VC 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 wrote:
| There's a bit of an answer to that from Charlie Marsh here:
| 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 wrote:
| Honestly, 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 wrote:
| Ah, that makes a lot of sense. Sounds like they have patient
| investors. They are doing amazing work.
| claytonjy wrote:
| the 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
| benatkin wrote:
| A Microsoft acquisition? Could help them to keep their open
| source trickery going. https://ghuntley.com/fracture/
| joshdavham wrote:
| These 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!
| jasonpeacock wrote:
| It'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
|
| And the best answer/description of what the type checker will be:
|
| https://github.com/astral-sh/ruff/discussions/15149
| smpretzer wrote:
| Another useful issue filter: https://github.com/astral-
| sh/ruff/milestone/20
| hooverd wrote:
| Very cool. I wonder where the codename comes from?
| zanie wrote:
| It's a joke about how Charlie didn't know Ruff was a bird.
|
| https://en.wikipedia.org/wiki/Red_knot
| __tyler__ wrote:
| My vote for the name was rype but it lost
| westurner wrote:
| Could 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 wrote:
| Have 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
| N1H1L wrote:
| I think TypeGuard (https://github.com/agronholm/typeguard)
| also does runtime type checking. I use beartype BTW.
| monlockandkey wrote:
| They 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
| roywashere wrote:
| I still hope they build a Heroku alternative. I think their
| work on uv might be some of the building blocks they would
| need?
| monlockandkey wrote:
| That sounds plausible. Vercel equivalent for the Python
| ecosystem. UV deploy
| joshdavham wrote:
| This is exciting! I'd love to be able to use something other than
| mypy, especially if it's way faster!
| IshKebab wrote:
| Pyright 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.
| CapeTheory wrote:
| When it comes time to write Python 4, please just let these guys
| handle it.
| g_delgado14 wrote:
| _let him coooook_
| binary132 wrote:
| "We're building a new high-speed seatbelt system for covered
| wagons"
| globular-toast wrote:
| Is 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 wrote:
| The 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
| mwt wrote:
| kinda 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 wrote:
| > 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.
| mwt wrote:
| thanks, I didn't know it was a thread because of the login
| wall
| dcreager wrote:
| np! I also posted a link to Charlie's Bluesky cross-post,
| which you can read without logging in to anything:
| https://news.ycombinator.com/item?id=42870359
| shlomo_z wrote:
| - They usually so a pretty good job adhering to standards
|
| - re: the money: https://news.ycombinator.com/item?id=42869358
| mwt wrote:
| Unfortunately that doesn't answer the question
| zem wrote:
| > - why not just contribute to the community tool?
|
| what community tool? mypy is written in python, and is non-
| incremental, whereas astral's goal is to build a fast,
| incremental type checker in rust. there is no way to get from
| one to the other via code contributions, they fundamentally
| need to start from scratch with their own architecture.
|
| as for the split in type checking tools, it is not as bad as
| you think; the syntax and to a large extent the semantics of
| the type system are defined via a community process and
| standardised upon, and the various type checkers largely differ
| in their implementation details but not in their interpretation
| of the code. so you can freely use several different type
| checkers without fear of disagreement.
| VeejayRampay wrote:
| nah actually we should keep the slow, subpar tooling we got
| now because it came first
|
| those people producing fantastic tools that have transformed
| the ecosystem of linting and packaging should be working on
| it instead of working on transformative tech
| mwt wrote:
| > as for the split in type checking tools, it is not as bad
| as you think
|
| I'm surprised you already know it's not as bad as I think -
| have you been able to use it? Working on a team that mixes
| mypy and pyright is pretty frustrating since they don't agree
| on everything (i.e. when one changeset passes on one and
| fails on the other) and I see no reason to believe the
| inconsistencies will become more rare when the number of
| opinions goes from two to three
| zem wrote:
| i worked on pytype for several years, and occasionally had
| to support projects that wanted to use multiple type
| checkers. in my experience, there were definitely times
| when one type checker would pass some code and another one
| reject it, but not code that would strictly work on either
| one checker or another but not both. it could be a pain
| trying to keep the strictest type checker happy when the
| other ones passed your code, but usually once you did that
| you were fine.
|
| also if you do find a case where two type checkers
| genuinely conflict on a piece of code, one or both of them
| would definitely like to see it as a bug report. if the
| underlying cause turns out to be undefined behaviour in the
| specs, the general typing community will work together to
| nail it down and the type checkers will all adapt. in
| general it is a very cooperative process that values the
| existence of a common set of standards, which is why I
| think having more type checkers will only improve the
| situation wrt nailing down corner cases in the specs.
| theLiminator wrote:
| Very 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 wrote:
| > 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
| IshKebab wrote:
| I 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 wrote:
| I'd appreciate knowing what's wrong with MyPy that this
| project will fix. Check time? Bad rules? Lack of features?
| tcdent wrote:
| yeah, 'awful' is just the OP being dramatic, though I am
| looking forward to Astral's contribution
| theLiminator wrote:
| I think that
| 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.
| arthur-st wrote:
| MyPy's rules are reference-grade, being as close to an
| official spec as we get until the Typing Council is done
| establishing their moat.
|
| To understand shortcomings of MyPy, I strongly suggest
| reading pyright's documentation for how they compare:
| https://github.com/microsoft/pyright/blob/main/docs/mypy-
| com...
|
| Quoting the pertinent part:
|
| > Pyright was designed with performance in mind. It is not
| unusual for pyright to be 3x to 5x faster than mypy when
| type checking large code bases. Some of its design
| decisions were motivated by this goal.
|
| > Pyright was also designed to be used as the foundation
| for a Python language server. Language servers provide
| interactive programming features such as completion
| suggestions, function signature help, type information on
| hover, semantic-aware search, semantic-aware renaming,
| semantic token coloring, refactoring tools, etc. For a good
| user experience, these features require highly responsive
| type evaluation performance during interactive code
| modification. They also require type evaluation to work on
| code that is incomplete and contains syntax errors.
|
| > To achieve these design goals, pyright is implemented as
| a "lazy" or "just-in-time" type evaluator. Rather than
| analyzing all code in a module from top to bottom, it is
| able to evaluate the type of an arbitrary identifier
| anywhere within a module. If the type of that identifier
| depends on the types of other expressions or symbols,
| pyright recursively evaluates those in turn until it has
| enough information to determine the type of the target
| identifier. By comparison, mypy uses a more traditional
| multi-pass architecture where semantic analysis is
| performed multiple times on a module from the top to the
| bottom until all types converge.
|
| > Pyright implements its own parser, which recovers
| gracefully from syntax errors and continues parsing the
| remainder of the source file. By comparison, mypy uses the
| parser built in to the Python interpreter, and it does not
| support recovery after a syntax error. This also means that
| when you run mypy on an older version of Python, it cannot
| support newer language features that require grammar
| changes.
|
| Astral's type checker seems to an exercise in speeding up
| Pyright's approach to designing a type checker, and
| removing the Node dependency from it.
| zelphirkalt wrote:
| I haven't had any issues from MyPy regarding speed. So
| performance issues did not exist whenever I used MyPy.
| Also not sure why I need incremental anything. I save a
| file and then I want it to be checked.
|
| If I am not implementing a LS, then how is it of any
| importance, whether the type checker was designed with
| typing a LS? How does that benefit me in my normal
| projects?
|
| If there are no semantic improvements, that allow more
| type inference than MyPy allows, I don't see much going
| for Pyright. Sounds like a "ours is blazingly faster than
| the other" kind of sales pitch.
| E_Bfx wrote:
| In a medium size codebase (~ 100 python modules of 200
| lines), mypy take 5 minutes to type check. This can be a
| problem for a CI.
| zelphirkalt wrote:
| Never happened for me. Similarly sized code base, done in
| seconds, if not 1s. Guess we all have our anecdotes.
| IshKebab wrote:
| I found performance not that different to Pyright. The
| major difference is quality and correctness. Mypy is full
| of weird bugs and insane typing holes.
|
| I found cases where it would even treat `foo: SomeType` and
| `foo # type: SomeType` differently!
|
| I tried to fix that one but looking into the code lowered
| my impression of it even further. It's a complete mess.
| It's not at all a surprise that it gets so many things
| wrong.
|
| Overall Mypy is like kind of like a type checker written by
| people who've only ever seen linters before. It checks some
| types but it's kind of wooly and heuristic and optional.
|
| Pyright is a type checker written by someone who knows what
| they are doing. It is mostly sound, doesn't just say "eh we
| won't check that" half the time, and has barely any bugs.
|
| Seriously check the closed/open issues on Github - there's
| a touch of "I disagree so I'm closing that" but only a
| touch. It mostly has so few open issues because the main
| author is a machine.
|
| The only real problems with it are performance (it's ok but
| definitely could be better), and the slightly annoying
| dependence on Node.
| zeotroph wrote:
| There is third, pytype (by google), which I found pretty good
| but it rarely gets mentioned. However, like the others it is
| slow, so I hope this one is fast and supports all the pytype
| features (especially being able to type-check un-annotated
| code).
|
| https://github.com/google/pytype?tab=readme-ov-
| file#pytype--...
| dcreager wrote:
| Bluesky cross-post for those who don't want to read the thread on
| X: https://bsky.app/profile/crmarsh.com/post/3lgvhzdfrps26
| timeon wrote:
| As someone without X or Bluesky, this link shows whole thread
| while X does not.
| uneekname wrote:
| Yeah, this is a better link. Can we swap it out?
| StackTopherFlow wrote:
| Doing the lord's work
| mixmastamyk wrote:
| I 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.
| agumonkey wrote:
| Applaud 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 wrote:
| > 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 wrote:
| as 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 wrote:
| this 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)
| zem wrote:
| yep, that's the one! I don't know if there's any one place
| to discuss gradual typing. typed racket is probably the
| language with the largest academic community behind it, so
| the racket discourse would likely have some good
| discussions, though I haven't been keeping up with it
| recently.
| agumonkey wrote:
| thanks a lot, i'll tag along the racketeers then, i was
| mostly curious to know if the field became wider,
| sometimes I get too focused on lisps and forget that
| other people are doing PLT
| intalentive wrote:
| I 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 wrote:
| You're in luck!
|
| https://github.com/mypyc/mypyc
| fuzztester wrote:
| Mojo 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://hn.algolia.com/?q=mojo
| pbronez wrote:
| Looks interesting. Their "magic" package manager scares me
| though. Not excited to curl | bash something with strong
| opinions about my local python setup
|
| curl -ssL https://magic.modular.com/deb11637-c8c3-4f76-9195-8
| 5af25ef2e... | bash
| ehutch79 wrote:
| My 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 wrote:
| is Django working towards using native types instead of all
| they stuff they invented before type hints existed?
| rtpg wrote:
| I 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 wrote:
| I 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
| IceWreck wrote:
| You should check out litestar
|
| It's essentially what you described and it's growing in
| popularity.
| adsharma wrote:
| It should be much easier to type check this:
|
| https://adsharma.github.io/fquery-meets-sqlmodel/
|
| https://github.com/adsharma/fastapi-shopping/blob/main/model...
| screye wrote:
| At 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 wrote:
| I 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 wrote:
| C types are almost entirely unlike modern type-checking
| jaredklewis wrote:
| Probably 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 wrote:
| I 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 wrote:
| I'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.
| adsharma wrote:
| Or a better python layer on python.
|
| People asking why statically typed python: consider that
| it's the #1 language on GitHub (assume ts and js are
| different) and LLMs are really good at generating it.
| harel wrote:
| But most people in our profession get to choose their job,
| don't they? Why would a Python project hire a rust
| programmer? Why would someone who hates Python work on a
| Python project? I feel the same way. Sporadic use of type
| hints is nice, and I use it sometimes for reference, like a
| very succinct comment. But if I want a typed language, Go,
| Dart, C or even Java are right there.
| mbo wrote:
| Because sometimes people choose their jobs prioritizing
| pay, location, title, company, project, role, coworkers,
| etc. and the language they will primarily use (or even use
| on a secondary basis) is a lower priority concern.
|
| In my case, I have, in the pursuit of my engineering goals,
| had to dig into a Python component that I did not normally
| work on or intend to work on. I am thankful it had type
| hints.
| tcdent wrote:
| typed python is amazing for building understandable
| applications. I will never go back.
|
| you can obviously still use it untyped to hack together
| scripts, but I still find myself leaving annotations for
| clarity.
|
| I've been using it since the mid 2.x days and find the style we
| were writing back then to be incredibly dated.
| RohMin wrote:
| I guess there's something about Python that just makes it
| really easy to read and write for me. I haven't found another
| language that fits the vibe. From my experience, the resentment
| towards stronger typing comes from developers misusing it.
| baq wrote:
| C is basically untyped but makes you type out the types. This
| is not what modern type checking is; it's usually the other way
| around - you specify types where you want them checked because
| it gives you confidence that the program is correct.
| mtalantikite wrote:
| The entire ML/AI ecosystem is in Python for the most part these
| days, so if anyone wants to get involved it means needing to
| touch Python to some degree. So, many developers might get
| handed projects that require working in Python, but would
| really prefer not to give up all the nice things that come from
| a modern statically typed language.
|
| Personally, I'm one of those people that got converted over to
| statically typed languages, as I spent a large part of my early
| career in startups using Ruby. I don't think I could ever go
| back after using Go, TypeScript, and Rust over the past decade
| or so.
| cobertos wrote:
| Progressive typing gives you the option to type check when and
| if you want or need it. You don't _have_ to type. If things get
| really hairy but you know it's right, you can focus on the code
| instead of the typing and efficiently complete your task.
|
| There's also something fundamental about taking a dynamic
| language like Python or JavaScript and adding typing versus
| taking a static language and adding dynamic typing (e.g.`auto`
| in C#). The dynamic language allows modifications that are
| _really_ convenient if not a little hacky that you just can't
| easily express without big refactors in static codebases.
| Things like tagging objects with properties, making quick
| anonymous structs (before that became a thing in modern
| languages) so you can return tuples of values, other constructs
| like dynamic functions or whatever. Progressive typing is just
| so much more expressive
| rewgs wrote:
| Man, I feel the exact opposite. Working without types, even if
| it's just type hints, feels like I'm stumbling around in the
| dark. I want to know what stuff _is,_ not just YOLO my way
| through everything.
|
| Looking at my Python before I began using type hints and data
| structures such as dataclasses, typevars, etc I was still type-
| checking a function's argument, but it was very manual and
| messy. Nowadays, my code is so much cleaner, concise, less
| error-prone, and much easier to revisit after a long period
| away. IMO there isn't a single downside to leaning heavily into
| types, even if they're sorta "fake" like they are in Python.
| falcor84 wrote:
| I personally just love Python type hinting for testing
| purposes. So I can avoid types while prototyping or playing
| with architecture, but once I have something I'm happy with, I
| find that adding types allows me to gain confidence in the
| program while having fewer tests, and generally making it
| easier to refactor further.
|
| And full typing is also a great first step for rewriting in
| another language.
| mixmastamyk wrote:
| _"Never give up, and good luck will find you."_
| taco_emoji wrote:
| I feel like if you think about it for 20 seconds you can come
| up with a lot of good reasons, so I question your motivation in
| posting this.
| 0xDEADFED5 wrote:
| i type hint for the poor bastards who have to use my code. it's
| a lot more pleasant to read and reason about.
| MathMonkeyMan wrote:
| It's an old debate.
|
| I used to prefer dynamically typed languages for most tasks,
| and saw attempts at statically typing everything as some kind
| of [compulsion][1].
|
| At work, we were writing a bunch of tests and tooling in
| python, and the team lead at the time insisted that we type
| things and lint with mypy strict as if it were a compiler.
|
| I said to my teammate "this is so stupid, if you want to know
| the types of the parameters, you read the documentation comment
| right there in the definition. If you want to know more, you
| read the test. If you want to know even more, you read the
| source."
|
| My teammate replied, "YOU will write a function with good
| documentation, thorough tests, and a comprehensible definition,
| but as an organization grows, a shrinking percentage of code
| will be written that way. These automated checks prevent the
| worst from coders who care less than you do."
|
| I had no retort, so there is that.
|
| [1]: https://github.com/dgoffredo/stag?tab=readme-ov-file#why
| nimish wrote:
| astral doing what the endless layers of admin/people in the PSF
| can't: solve actual problems python devs face
| aldanor wrote:
| Final piece of the puzzle will be one LSP to rule them all,
| unifying all previous work - aka python-analyzer.
___________________________________________________________________
(page generated 2025-01-29 23:00 UTC)