4 ms·

This is very cool but why wouldn’t they just contribute to uv and ruff and ty https://github.com/astral-sh/ty https://github.com/astral-sh/ty

ldng 1y ago
NIH + copyright
- trostaft 1y ago
  Isn't both this and ty MIT license?
djinnish 1y ago
I think astral and meta were both working on their own type-checkers independently. My current understanding is that meta released so they could preempt the initial release of ty. It seems like they're a bit further ahead in development. Not sure if there are going to be any real differences between the two down the line.
- bsimpson 1y ago
  Sounds a lot like TypeScript and Flow.
  - surajrmal 1y ago
    Typescript was Microsoft though. Meta might have the edge here based on brand awareness, but who knows for sure.
    - bsimpson 1y ago
      Right, and Flow was FB
  - singhrac 1y ago
    Sure, but in this case they are both implementations of a spec defined by PEPs, so a bit more like gcc vs clang (less tightly bound than those, of course, in design decisions). Neither company is trying to invent a new language here.
    - maleldil 1y ago
      The current major type checkers, mypy and pyright, are also based on the same PEPs, but you can still see differences between them. For example, my codebase passes pyright in strict mode, but mypy results in a bunch of type errors. I'd expect pyrefly and ty to be slightly different from each other. See also: https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com... https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html https://htmlpreview.github.io/?https://github.com/python/typ...
      - singhrac 1y ago
        Sure, I agree. I’m just saying that most of their defacto disagreements are because of ambiguity in the specs, not because one of them is (intentionally) choosing to fork. Fwiw I think performance and features are kind of intertwined here, since Pyright’s extra speed makes it possible to infer more things that are not easy for mypy, especially in an LSP implementation. Pyright is very impressive in that second link (conformance check), very much a product of Eric Traut & others dedicating a lot of energy to this single problem.
    - zem 1y ago
      the specs are still evolving, and the various type checker implementations are what is driving them forward. in general, capturing the dynamic typing semantics of python in a gradually typed system is not a fully solved problem, and the type checkers are experimenting with various approaches to it.
- singhrac 1y ago
  I think they've mentioned earlier that it's really just because PyCon is this week (so a good time to announce new Python tooling).
simonw 1y ago
ty is so new right now - it only got its current name a few weeks ago!
- baggiponte 1y ago
  That’s not true, they have been developing it as red knot for a good while :)
  - simonw 1y ago
    Like I said, it only got its name a few weeks ago.
colesantiago 1y ago
Because this has been tested at Meta / Facebook scale which means it's faster for any Python codebase massive and small. Since Meta built this, I have confidence this will be maintained more than others and I will use this and ask for Pyrefly experience in the future.
- WD-42 1y ago
  I suggest you try uv and ruff and then see if you still think only companies the size of meta can provide quality tooling.
- 0xFF0123 1y ago
  This feels like a somewhat closed minded approach given both tools are in their infancy
munro 1y ago
That's sort of how I felt about things before, but the reality I believe is we wouldn't have uv if they 'just contributed to poetry'.
- mnahkies 1y ago
  I tend to agree. I don't know the differences between the two well enough to know if it was the case here, but in my experience sometimes you need to innovate on a fork, or from scratch in order to create the space/freedom to do so. Once a project is popular, it's harder to justify and be confident about major changes (aka https://m.xkcd.com/1172/ https://m.xkcd.com/1172/)
  - WD-42 1y ago
    It seems like the share a lot of the same goals but my impression is Poetry is much slower to pick up on standards. It’s normal to use uv with a project now that doesn’t have any [tool.uv] section in pyproject.toml at all but every poetry project I’ve seen is littered with [poetry] sections, even dependencies. Makes me not want to use it
koakuma-chan 1y ago
I just ran ty and it can't resolve any imports whereas pyrefly passes. Why would that be? I hate Python so much.
- zanie 1y ago
  ty doesn't invoke a Python interpreter to discover imports yet — so you need to either set `VIRTUAL_ENV` or pass `--python` to configure your target environment. We'll expand support here in the future, but this part of ty's interface is intentionally minimal while we focus on core type checking features.
- akdor1154 1y ago
  > I hate Python so much. Look I get that it's frustrating, but the tool you're whinging about is literally pre-alpha.
- zem 1y ago
  I love the language, but I do hate the import system too, it makes everything harder
  - koakuma-chan 1y ago
    I just put __init__.py everywhere, not sure it does something but to be safe
deleted 1y ago
[deleted]

ldng 1y ago

NIH + copyright

trostaft 1y ago
Isn't both this and ty MIT license?

djinnish 1y ago

I think astral and meta were both working on their own type-checkers independently. My current understanding is that meta released so they could preempt the initial release of ty. It seems like they're a bit further ahead in development. Not sure if there are going to be any real differences between the two down the line.

bsimpson 1y ago
Sounds a lot like TypeScript and Flow.
- surajrmal 1y ago
  Typescript was Microsoft though. Meta might have the edge here based on brand awareness, but who knows for sure.
  - bsimpson 1y ago
    Right, and Flow was FB
- singhrac 1y ago
  Sure, but in this case they are both implementations of a spec defined by PEPs, so a bit more like gcc vs clang (less tightly bound than those, of course, in design decisions). Neither company is trying to invent a new language here.
  - maleldil 1y ago
    The current major type checkers, mypy and pyright, are also based on the same PEPs, but you can still see differences between them. For example, my codebase passes pyright in strict mode, but mypy results in a bunch of type errors. I'd expect pyrefly and ty to be slightly different from each other. See also: https://github.com/microsoft/pyright/blob/main/docs/mypy-comparison.md https://github.com/microsoft/pyright/blob/main/docs/mypy-com... https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html https://htmlpreview.github.io/?https://github.com/python/typ...
    - singhrac 1y ago
      Sure, I agree. I’m just saying that most of their defacto disagreements are because of ambiguity in the specs, not because one of them is (intentionally) choosing to fork. Fwiw I think performance and features are kind of intertwined here, since Pyright’s extra speed makes it possible to infer more things that are not easy for mypy, especially in an LSP implementation. Pyright is very impressive in that second link (conformance check), very much a product of Eric Traut & others dedicating a lot of energy to this single problem.
  - zem 1y ago
    the specs are still evolving, and the various type checker implementations are what is driving them forward. in general, capturing the dynamic typing semantics of python in a gradually typed system is not a fully solved problem, and the type checkers are experimenting with various approaches to it.
singhrac 1y ago
I think they've mentioned earlier that it's really just because PyCon is this week (so a good time to announce new Python tooling).

simonw 1y ago

ty is so new right now - it only got its current name a few weeks ago!

baggiponte 1y ago
That’s not true, they have been developing it as red knot for a good while :)
- simonw 1y ago
  Like I said, it only got its name a few weeks ago.

colesantiago 1y ago

Because this has been tested at Meta / Facebook scale which means it's faster for any Python codebase massive and small. Since Meta built this, I have confidence this will be maintained more than others and I will use this and ask for Pyrefly experience in the future.

WD-42 1y ago
I suggest you try uv and ruff and then see if you still think only companies the size of meta can provide quality tooling.
0xFF0123 1y ago
This feels like a somewhat closed minded approach given both tools are in their infancy

munro 1y ago

That's sort of how I felt about things before, but the reality I believe is we wouldn't have uv if they 'just contributed to poetry'.

mnahkies 1y ago
I tend to agree. I don't know the differences between the two well enough to know if it was the case here, but in my experience sometimes you need to innovate on a fork, or from scratch in order to create the space/freedom to do so. Once a project is popular, it's harder to justify and be confident about major changes (aka https://m.xkcd.com/1172/ https://m.xkcd.com/1172/)
- WD-42 1y ago
  It seems like the share a lot of the same goals but my impression is Poetry is much slower to pick up on standards. It’s normal to use uv with a project now that doesn’t have any [tool.uv] section in pyproject.toml at all but every poetry project I’ve seen is littered with [poetry] sections, even dependencies. Makes me not want to use it

koakuma-chan 1y ago

I just ran ty and it can't resolve any imports whereas pyrefly passes. Why would that be? I hate Python so much.

zanie 1y ago
ty doesn't invoke a Python interpreter to discover imports yet — so you need to either set `VIRTUAL_ENV` or pass `--python` to configure your target environment. We'll expand support here in the future, but this part of ty's interface is intentionally minimal while we focus on core type checking features.
akdor1154 1y ago
> I hate Python so much. Look I get that it's frustrating, but the tool you're whinging about is literally pre-alpha.
zem 1y ago
I love the language, but I do hate the import system too, it makes everything harder
- koakuma-chan 1y ago
  I just put __init__.py everywhere, not sure it does something but to be safe

deleted 1y ago

[deleted]