Thank you for engaging with ty!

Before opening an issue on this repository, note that ty is currently in preview and not ready for production use.

That said, we are very much interested in getting feedback. Before opening a new ticket, please search the issue tracker for existing issues. In particular, please take note of the following known ty issues that users are likely to run into on larger projects — if your issue is captured here, we're aware of it and there's no need to open a new issue. Please add a 👍 reaction on the top comment rather than commenting with "me too", etc.

• Fatal errors for self-self-referential (recursive) generic classes, type aliases, or protocols
  ty currently crashes for various self-referential constructs like generic classes, type aliases or protocols. For example:

  type C = dict[str, "C"]
  
  class A[T: "A"]:
    pass

  Common symptoms:

  • ty crashes with "A fatal error occurred while checking some files". The panic message (search for "Panicked at") includes the message "too many cycle iterations"
  • Same as above, but the message includes "dependency graph cycle" instead.
  • ty hangs
  • ty crashes with a stack overflow

• Missing support for starred/splatted/unpacked arguments in function calls

  ty currently does not recognize double-starred arguments:

  def f(a: str, b: int): pass
  
  opts = {"name": "foo", "n": 2}
  f(**opts)  # missing-argument

  ty does support single-starred arguments:

  def g(x: int, y: int, z: int): pass
  numbers = (1, 2, 3)
  g(*numbers)

  Common symptoms:

  • Invalid missing-argument diagnostic in a call with a double-starred argument
  • Invalid no-matching-overload diagnostic in a call with a double-starred argument

• No support for typing.TypeAlias
  We currently do not support typing.TypeAlias and infer special @Todo types (that act like Any) for symbols that are annotated with such aliases:

  from typing import TypeAlias
  
  IntOrStr: TypeAlias = int | str
  
  def f(x: IntOrStr):
      reveal_type(x)  # @Todo

  Common symptoms:

  • This can lead to false negatives (a diagnostic was expected but did not show up)
  • It can also lead to false positives because we wrongly think that something is assignable, for example:
    • Wrong overload is picked in a call, if parameter types are annotated with type aliases like various path variants (BytesPath, StrPath, GenericPath, …) or file.open mode arguments (OpenTextModeReading, OpenTextModeWriting …).

• No implicit import of submodules

  If you import some_module, ty will not let you access attributes on submodules (some_module.some_submodule.SubmoduleClass), unless you explicitly import module.submodule as well.

  Common symptoms:

  • unresolved-attribute diagnostics on modules (Type <module 'some_module'> has no attribute some_submodule)