false positive syntax errors when using syntax for newer python version in `.pyi` files

[DetachHead]

Summary

# foo.pyi

def foo[T](): ...

type Foo = int

Cannot use type parameter lists on Python 3.8 (syntax was added in Python 3.12)
Cannot use `type` alias statement on Python 3.8 (syntax was added in Python 3.12)

since .pyi files are not executed at runtime, they should be able to use newer syntax than the target python version

Version

0.14.6

[MichaReiser]

Thanks for reporting. Yes, that makes sense. @ntBre I think this would be great to fix unless a contributor gets to it first :)

One option is to ensure we always pass the latest Python version to parse if the file is a pyi file, or we add a new option to ParseOptions to signify whether we're parsing a stub file (requires reviewing all call sites)

[11happy]

I have linked the PR fixing it.
Thank you : )

[AlexWaygood]

since .pyi files are not executed at runtime, they should be able to use newer syntax than the target python version

while this is true, the most popular type checker (mypy) currently uses the Python ast module to parse all Python files, including .pyi files. If mypy is invoked using Python 3.11, it won't be able to parse syntax introduced in Python 3.12. So if a .pyi file uses Python 3.12+ syntax, it won't be usable with mypy unless you use Python 3.12 or newer to invoke mypy. I don't think that's what most authors of stubs would want: I think most authors of stubs would want their stubs to be legible by all type checkers, regardless of what Python version you use to invoke that type checker.

[DetachHead]

the way i see it, mypy's days as "the most popular type checker" are numbered, so ruff should not be held back by it. ruff should be able to support projects that don't care about supporting mypy anymore. i would think any project that cares about mypy support on older python versions versions would already be running mypy with that version of python in their CI anyway, so i don't think it's ruff's responsibility to account for this. but i guess this behavior could be configurable if this is really a concern?

[AlexWaygood]

As a developer of ty, I obviously hope that ty succeeds :-)

And as a developer of typeshed, I would of course love to be able to use the latest and greatest Python syntax when writing stubs!

But as an author of Python libraries, and a developer of typeshed, I would very much want any stubs I write to work with whatever type checker a user of my library might be using. Whether you're a fan of mypy or not, the fact of the matter is that for many users that type checker is currently mypy, and it will continue to be mypy for many users for many years to come, even if it loses its spot as the most popular type checker.

There has been talk over at mypy of switching to a new parser (possibly the Ruff parser!), so it would be interesting to revisit this discussion if and when that happens. But unless and until that happens, I would definitely at least want to be able to opt into these syntax errors on .pyi files (and making them opt-out makes most sense IMHO).

[MichaReiser]

(and making them opt-out makes most sense IMHO)

which they already are. Or more specifically, you can opt-out of the syntax errors by using per-file-target-version and setting it to 3.14 for all pyi files