ruff: False positive with F401 (imported but unused) for type comments

@charliermarsh maybe 1 area that this is still useful in Python 3.6+: type hinting the result of a context manager. Example:

from types_aiobotocore_s3 import S3ServiceResource

async with self.boto_session.resource("s3") as s3:  # type: S3ServiceResource
    obj = await s3.Object(self.bucket_name, key)
    return (await obj.get())["Body"]

The from types_aiobotocore_s3 import S3ServiceResource part is removed by ruff.

Looks like leaving it off or on is ok by Mypy, but type hinting at least in Pycharm is better with the type comment.

Similar to https://github.com/charliermarsh/ruff/issues/1619#issuecomment-1406845028, I still use type comments in some very rare cases where things like for loops don’t have syntax to express a “real” Python 3 type hint and the type checkers can’t infer the type due to limitations in the underlying libraries being used.

from models import Wheel

for wheel in car.wheels.all():  # type: Wheel
    ...

I realize this is non-standard, but PyCharm will interpret this and provide intellisense/auto-complete for the loop variable, which is practically useful in these niche cases.

Also, it’s worth mentioning that if you unpack values in this manner:

n: str
p: Tensor
r: Tensor
f1: Tensor
for n, p, r, f1 in zip(names, precision, recall, f1_micro):
    ...

it seems unnecessarily complicated for such a simple functionality compared to a simpler approach like:

for n, p, r, f1 in zip(names, precision, recall, f1_micro):  # type: str, Tensor, Tensor, Tensor
    ...

+1 would also be very helpful to be able to use type comments. IMO they’re much nicer than normal type annotations in a lot of places, because they can “hide” as a comment out of site of the actual line of code

(Thank you, these comments are all welcome and helpful.)

Yeah we don’t really support type comments right now, since they were made obsolete in Python 3.6 AFAIK. I know some projects still use them for compatibility… I’ll think on it.

They are not obsolete, they are part of PEP 484 specification and are supported by all major type checkers (pyright, mypy, pyre, etc) https://peps.python.org/pep-0484/#type-comments

There are a ton of projects that leverage them, i.e. numpy.

@JonathanPlasse Good point bringing that up. I’ve generally been a little resistant to this particular fix because it complicates the actual code just to add the hint:

• It creates a new unbound local (if the code gets refactored later it could open up the possibility that s3: S3ServiceResource gets “separated” from the loop accidentally)
• Python leaks loop variables into the outer scope already, but the new s3: S3ServiceResource could be misunderstood as implying intent to leak the iterator
• There is a DRY issue where if the loop variable s3 is renamed but the outer typed variable isn’t

But you’re right that this is the officially prescribed way of dealing with it, but hopefully the above points help explain why people may be hesitant to do it just for a hint.

All type comments can be replaced (c.f.: https://peps.python.org/pep-0526/#where-annotations-aren-t-allowed)

from types_aiobotocore_s3 import S3ServiceResource

async with self.boto_session.resource("s3") as s3:  # type: S3ServiceResource
    obj = await s3.Object(self.bucket_name, key)
    return (await obj.get())["Body"]

# Becomes
s3: S3ServiceResource
async with self.boto_session.resource("s3") as s3:
    obj = await s3.Object(self.bucket_name, key)
    return (await obj.get())["Body"]

from models import Wheel

for wheel in car.wheels.all():  # type: Wheel
    ...
# Becomes
wheel: Wheel
for wheel in car.wheels.all():
    ...

Maybe the issue title can be change to False positive with F401 (imported but unused) with mypy type comments ? can faster be found when searching for this issue.

Affects me as well.

is there any reason to use type comments when writing Python code today?

The company where I work has multi-million line codebase and we just migrated to using ruff as THE linter. (thank you for the great project!)

It’s not possible to migrate the whole codebase in a one go to the py3 comments unfortunately (there are technical reasons why we cannot do that).

@charliermarsh

is there any reason to use type comments when writing Python code today?

As explained in the link below, for the rare cases of needing to type hint loop variables or with block variables, I find type comments avoid several drawbacks:

• https://github.com/astral-sh/ruff/issues/1619#issuecomment-1557012758

@charliermarsh personally I use them exclusively, (see my previous comment https://github.com/astral-sh/ruff/issues/1619#issuecomment-1518178907), purely because I think they make code much more readable. But thats just my 2c 🤷🏼‍♂️

I stumbled onto this issue in the configparser project. I worked around it by converting the type comments to native type hints (jaraco/configparser@4990ba132450e218d9695ba74d4a139913459b17).

I’d say the comment looking nicer than a type annotation is an editor/highlighter problem, but the general point of this being useful is correct.

Yeah exactly! mypy will complain that it isn’t defined if the import is missing, i.e.

kodiak/pull_request.py:76:5: error: Name "List" is not defined  [name-defined]
kodiak/pull_request.py:76:5: note: Did you forget to import it from "typing"? (Suggestion: "from typing import List")