HN

Comments (92)

• Menu

  miki123211
  I am a Python programmer. I love Astral; I think Ruff is great and uv is life-changing, but I don't actually like ty that much.I want my type checker to check types and to scream at me when it can't. I don't want it to do "gradual typing", if it is unsure about what type something is, I want that to be a failure instead of it modeling the unsureness and not showing potential errors. We live in the age of agents, having to add an extra annotation here and there is not so much of a problem any more.Meta's Pyrefly largely does what I want. I don't quite love Pyrefly either; I don't like the fact that it edge-cases and gives monopoly status to some popular packages (Pydantic, Django, attrs) instead of offering generalized mechanisms that less popular packages could also utilize, but purely on a type checking front, it's excellent.
• Menu

  assumed_throwaw
  I love Astral’s tools, but I wonder why the CLI feels so fragmented.- Now, ty is integrated into uv, while ty is technically being part of ruff [1], but ruff is not integrated into uv.- The formatter is part of ruff, but uv also have an undocumented "format" command, which does not produce the same results.- Actually, ruff is integrated into uv, but you must call it through "uv tool run ruff".I guess I'd like "uv format" and "uv lint" to become the standard commands.[1] https://github.com/zed-extensions/pyrefly/issues/26#issuecom...
• Menu

  WhyNotHugo
  I dislike the idea of these separate tools being blended like this. ty is currently perfectly usable on non-uv projects. uv has *a lot* of opinionated quirks, its custom lockfile lockfile, and other nuances which many of us dislike — ty being a separate tool works fine with plain pip plus any other dependency manager (e.g.: pip-tools).Of note though, ty doesn't NEED to be integrated into uv, nor vice-versa; keeping them as standalone tools seems most natural.
• Menu

  olive-n
  I feel like pyrefly was gaining some traction over the year. I started using it this week.This seems like astral realizing they lost the type checker race and now fold it into their popular project so people have a reason to use it.If it is already installed with uv, people have less reason to look for a type checker and will just stay with the default option.
• shahbazac
  I’m not a fan of ‘uv run …’ and other tools interfering with running scripts or programs. I hope core Python developers are looking to “protect” the main interface for using Python. I don’t necessarily mean this in an adversarial way, but more and more QuickStart and installation pages for software require the use of uv, conda, 20 variations of venv, etc.There is clearly a gap in tooling. We have had a cambrian explosion of tools and we have tried many options. Now it is time for core Python folks to step in and consolidate the ecosystem.
• bitpush
  I really really love uv but this uv-ty post seems "shipping the org chart"?They could have just said uv now has type chancing capabilities (or whatever it is ..) ty afaik isn't a super popular brand so the post makes people first understand what ty is ..
• Menu

  thayne
  It seems like it would make more sense for ty to be integrated with ruff than uv.
• grandimam
  This feels more like we are moving towards a Bun-like model where tooling becomes a unified runtime experience, handling everything from dependency management, package, linting, type checking and finally execution. To me, merging uv, ruff, and ty seems like a natural organizational step.
• Menu

  xavdid
  Ah, this is great! It's a step towards solving my biggest complaint with PEP 723 scripts: bad editor support.I loved the idea on paper, but without manually creating a matching venv & installing my deps, I wouldn't get in-editor completions during development. That was fine for small things, but intolerable as the script grew. So it's still not a feature I've used much, since it made more sense to just make a real dev environment.I'm glad to see there'll be improvements here!
• Menu

  nehalem
  I fundamentally appreciate the single tool toolchain but ty‘s hesitant support of Django(’s quirks) preempts the advantages for me.
• JoshCLWren
  I just removed ty from our codebases at work in favor of Pyrefly which is everything I wanted from ty. We're gradually going to a strict-typed python and Ruff and UV are incredible but ty has been a disappointment. In my personal projects I've replaced ty with mypy as an experiment to see how much it improves agentic coding. I bought into the idea of ty being eventually good enough but in the last year or so it hasn't happened.
• dirtbag__dad
  This is what’s up! Having worked on several medium sized python projects where linting and type checking were introduced late in the game, having them as a first class feature of the package manager will save so much unnecessary pain.IMO, part of the problem is that people just don’t know that linters or tools like this exist at all. This is the best type of product marketing where the product gets meaningfully better, while educating the users for free.
• MaxMonteil
  Maybe this is somewhat inspired by the consolidation happening in JS land with Vite Plus and Void 0.Vite+ is making it easier to use their linting, formatting (, and more) together though they can still operate fully independently.
• Menu

  flexagoon
  I'm really glad that unlike most other recent acquisitions, OpenAI's acquisition of Astral had seemingly no negative impact on their products
• Menu

  Philpax
  One step closer to bringing the Rust experience to Python. Good.
• karpetrosyan
  It's cool to see ty support for scripts. That's something I really needed, and I even developed an extension to solve it: https://github.com/karpetrosyan/uv-vscode
• kaangiray26
  it seems like they've also solved the inline metadata dependencies syncing in scripts finally. so if you declare script dependencies you'll no longer see module not found errors from that
• Menu

  dsp_person
  what happened to pyx?
• Menu

  shevy-java
  I can't help it - this sounds not that exciting.Has the world shifted so much in the last years? I remember when I switched to Linux, many years ago, I worked through LFS (Linux from Scratch) within, say, one or two years. Back then that was kind of exciting; since then I expanded my own scripts for compiling or installing things, including versioned AppDirs, which to me are a lot more logical and elegant too. Why would I need or use uv? Does uv even support versioned AppDirs? How about multiple different glibc on the same system (hint: that works though you have to take care of how things are setup; think of an extended NixOS-like system, with guarantees).uv seems to be hyped a lot and I still do not understand why.
• arbor-group
  [flagged]
• agentkitco
  [flagged]
• ZeroDayDreamer
  [flagged]
• geophph
  [dead]
• nredd
  [flagged]
• Menu

  frumiousirc
  Am I alone in thinking type hints are largely a waste of time in Python and can be actively harmful?I had claude run ty via this new "uv check" on a moderately sized Python package (cli+tui to a multi-transport messaging system) and it found 67 things. Claude checked each finding for bugginess and found 1 is marginally worth fixing. A large fraction of the findings were ty guessing the type and being wrong. Hinting would I guess remove those wrong guesses but hinting is a PITA and greatly increases code size, both of which is bad for human and LLM.Do people really get benefit from going all-in with type hinting?