_carljm · HackerTrans

4 เดือนที่ผ่านมาdiscuss

We provide this diagnostic in ty (https://docs.astral.sh/ty/reference/rules/#possibly-unresolv...), but it's disabled by default because it can have false positives in many scenarios where the code works at runtime (this is true also in the type checkers that enable it by default). A typical example is code like

  def _(flag: bool):
    if flag:
      x = True
    ...
    if flag:
      read(x)

But it's easy to turn the rule on if you want it:

  [tool.ty.rules]
  possibly-unresolved-reference = "error"

_carljm

7 เดือนที่ผ่านมาdiscuss

https://forum.cursor.com/t/newly-published-extensions-appear... suggests that there's some kind of delayed daily update for new VSCode extension versions to become available to Cursor? It seems likely that's what is happening here, since ty-vscode 0.0.2 was only published an hour or two ago.

_carljm

7 เดือนที่ผ่านมาdiscuss

I can reproduce this; we're looking into it.

_carljm

7 เดือนที่ผ่านมาdiscuss

We'll be adding ourselves to that table soon. We'll have some work to catch up with pyright on conformance, but that's what the time between now and stable release is for.

_carljm

ปีที่แล้วdiscuss

There are ways to type invariant generics more precisely that still meet the gradual guarantee. E.g.:

  x = []  # list[Unknown]
  x.append(A())  # list[Unknown | A]
  takes_list_of_a_or_b(x)  # list[A | B]

We haven't decided yet if this is what we want to do, though. It's also possible that we may decide to compromise on the gradual guarantee in this area. It's not an ironclad rule for us, just something we're considering as a factor.

_carljm

ปีที่แล้วdiscuss

ty also implements gradual set-theoretic types, and can represent "ranged" dynamic types (as intersections or unions with Any/Unknown). We don't currently refine dynamic type based on all uses, as suggested here, though we've considered something very much like this for invariant generics.

In your example, wouldn't `none()` be a type for `x` that satisfies both `Integer.to_string(x)` and `Atom.to_string(x)`? Or do you special-case `none()` and error if it occurs?

_carljm

ปีที่แล้วdiscuss

This information is already maintained via `if sys.version_info >= (...):` conditionals in typeshed stubs. I don't think this is important enough to justify maintaining the same information in a duplicate way.

_carljm

ปีที่แล้วdiscuss

I agree that would be nice; probably not near the top of our list right now (and not trivial to implement), but it makes sense. Thanks for the suggestion.

_carljm

ปีที่แล้วdiscuss

Yes, thank you for your graciousness and generosity, very much appreciated.

_carljm

ปีที่แล้วdiscuss

I knew we left something important out of that onboarding document

_carljm

ปีที่แล้วdiscuss

Not the same headline functionality yet, no. At the moment all we support is diagnostics (some of which may be wrong) and go-to-type-definition. More will come.

_carljm

ปีที่แล้วdiscuss

Yes, we've talked; I know a number of the pyrefly devs well. Ty had already been months in development when pyrefly development started. We discussed collaboration, but they decided they needed to do their own thing in order to move quickly and ensure it would serve their needs, which is totally reasonable.

_carljm

ปีที่แล้วdiscuss

There's a good chance many of the errors we emit are incorrect, at this stage. Lots to do still!

_carljm

ปีที่แล้วdiscuss

The current version can handle importing pydantic without error just fine, but it probably can't find your virtualenv, so it doesn't know what third-party dependencies you have installed. Ty will discover your venv if it is in `.venv` in the project directory; otherwise you can help it out with the `--python` CLI flag.

_carljm

ปีที่แล้วdiscuss

Yes, red knot was the internal development code name; ty is the actual name.

_carljm

ปีที่แล้วdiscuss

We're looking forward to hearing what your experience is! There's a certain amount of roughly-constant overhead (e.g. reading all the files), so generally ty will look relatively faster the larger the project is. For very large projects we've seen up to 50-60x faster or more. We haven't really put a lot of work into targeted optimization yet, so we aim for it to get faster in the future.

It will certainly be slower than Ruff, just because multi-file type analysis more complex and less embarrassingly parallel than single-file linting.

_carljm

ปีที่แล้วdiscuss

(ty developer here)

Currently we default to our oldest supported Python version, in which `datetime.UTC` really doesn't exist! Use `--python-version 3.12` on the CLI, or add a `ty.toml` with e.g.

``` [environment] python-version = "3.12" ```

And we'll find `datetime.UTC`.

We've discussed that this is probably the wrong default, and plan to change it.

_carljm

ปีที่แล้วdiscuss

(ty developer here)

This is an early preview of a pre-alpha tool, so I would expect a good chunk of those 3500 errors to be wrong at at this point :) Bug reports welcome!

_carljm

5 ปีที่แล้วdiscuss

"Open it and see if there is interest" is the first step in "offer to work to upstream it." Not sure where you got the idea that it's only the former and not the latter.

_carljm

5 ปีที่แล้วdiscuss

We've been calling it Cinder internally for years, long before we thought about opening it up. If we wanted to make it a big branded thing, we'd work on finding a unique name for that, but we aren't trying to do that, we're just opening the code to make it easier to share work with upstream and other people working on CPython performance. We hope libcinder keeps the mindshare around the "cinder" name.

comments