Skip to content

Conversation

@maifeeulasad
Copy link

Description

closes #1313

Tests and Documentation

@maifeeulasad maifeeulasad marked this pull request as draft January 17, 2026 08:01
@maifeeulasad
Copy link
Author

Note 1: There is no pre commit hook for ty as of today (2026.01.17)

"We don't plan on adding this right now because ty is still at a very early, experimental stage and we don't want to give the impression that it's ready for serious production use yet. When we're closer to feature-complete, however, we'll absolutely be adding this." - Alex Waygood

ref:

@maifeeulasad
Copy link
Author

Note 2: await outside func/async function

We are getting errors saying

  • error[invalid-syntax]: *await* statement outside of a function
  • error[invalid-syntax]: *await* outside of an asynchronous function

It is something under discussion there:

Interesting. What are the options we have here?

Keep it a rule
Introduce parser options (per file?)
Always allow
-- Micha Reiser

And then we got reply saying:

I don't think this is a realistic option for non-notebook files: for the vast majority of Python code this is a syntax error; we should definitely flag it by default for non-notebooks.

I'm not totally familiar with the situation for notebooks, honestly, as I've never seriously used notebooks. I can't tell you whether top-level awaits are allowed by default in notebooks or if it's only if some settings are enabled. I believe they're much more common in notebooks than in regular Python source code, however. For notebooks, we may want it to be an opt-in diagnostic rather than an opt-out diagnostic.

And even for regular Python source code, we'll want this to be at least suppressible on a per-file basis. Although it's pretty rare to use ast.PyCF_ALLOW_TOP_LEVEL_AWAIT for non-notebooks, it is possible.

I don't have strong opinions on how we make this diagnostic suppressible -- whether it stays as a linter rule or if you add per-file parser options.
-- Alex Waygood

I think it will take quite a while to get this feature.

ref:

 - `ty` doesn't have any allow empty body config afaik
@maifeeulasad
Copy link
Author

Here is existing mypy configuration:

[tool.mypy]
plugins = []
ignore_missing_imports = true
strict = false
follow_imports = "silent"
strict_optional = false
disable_error_code = ["empty-body"]
exclude = ["doc/code/"]

And here is what I am migrating into:

[tool.ty]
[tool.ty.rules]
unresolved-import = "ignore"
possibly-missing-attribute = "ignore"
unused-ignore-comment = "ignore"
[tool.ty.analysis]
respect-type-ignore-comments = true
[tool.ty.src]
exclude = ["doc/code/"]

And here is my mapping, or the reason:

mypy flag visible behavior ty rule
ignore_missing_imports = true no import errors unresolved-import = "ignore"
strict_optional = false None tolerated possibly-missing-attribute = "ignore"
disable_error_code = ["empty-body"] empty bodies allowed no equivalence
legacy mypy behavior allow unused # type: ignore unused-ignore-comment = "ignore"

Open for discussion, if I am missing something. Just wanted to clarify.

ref:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MAINT Replace mypy with ty

1 participant