facebook
Type comments
AFAIK Pyrefly doesn't support type comments for type hints like others do, such as Pylance. Although this isn't an issue for those using Python 3.5+, type comments are really helpful for me and possibly others who struggle with projects in older versions of Python.
Pyrefly does offer great performance improvements, which is why I switched to it. However, the lack of support for type comments is really a pain point for me, and I hope Pyrefly consider adding this feature🙏
Some examples, more info here
a = 1 # type: int
def foo(a, b): # type: (int, int) -> int
return a + b
Originally posted by @sjet47 in https://github.com/facebook/pyrefly/discussions/407#discussioncomment-14381577
I was under the impression we were not going to support versions of Python older than 3.9. I know projects running versions of Python newer than 3.5 can still have type comments, but I'm not sure it's something worth adding/maintaining, unless it's something that doesn't take much effort on our part.
Are there tools that can convert type comments to inline types?
I would venture to say that it is worth supporting since there are some pretty popular libraries (such as sentry which is a mainstay in a large % of python projects) that use them
@trevor-inflection
I'm curious about the (int, int) -> int and () -> Generator[Scope, None, None] - this isn't legal syntax for a regular type annotation, since PEP 677 was rejected.
Is there a place that defines the grammar for type comments?
Also, in #1434 you mention that ty handles type comments, but I don't think it does https://play.ty.dev/977f215f-bb2f-4636-9ca5-ad4946f775c1
Mypy does support this, but I'm hoping the grammar for these comments is defined by something other than mypy's parser implementation.
@yangdanny97
You are right that ty doesn't seem to infer the correct type, but it does not raise errors in their LSP atm, which is why I had thought it was working there as well.
I am not sure on the exact grammar, but it seems like the function type comment is disjoint from PEP 677 and was the standard way to annotate functions prior to the non-comment syntax was introduced (https://peps.python.org/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code).
It definitely is for very legacy code and it might be suitable to skip type checking for functions/parameters annotated if that is possible
This does hurt adoption of pyrefly as not all annotations are "user controlled".
For example, https://github.com/pnuckowski/aioresponses types its main object:
class aioresponses(object):
"""Mock aiohttp requests made by ClientSession."""
_matches = None # type: Dict[str, RequestMatch]
_responses: List[ClientResponse] = None
requests = None # type: Dict
mypy and others pick up on this correctly, which means we likely can't switch to pyrefly (or have it turn it off for our tests directory).
I looked into this more & found a section in PEP 484 on type comments: https://peps.python.org/pep-0484/#type-comments along with the implementation code for Mypy. Thanks @trevor-inflection for the link re: function syntax
If we do implement it (I'm not 100% convinced we should), it would be a best-effort thing where we try to parse the thing after type, and if it does not parse we should just fall back and pretend the annotation doesn't exist. When resolving the annotation, if it doesn't resolve to a valid type, again we should probably skip it.
We should also give a warning when people try to use type comments (similar to Pyright), since it's a legacy feature that will likely go away some day.
Supporting # type: (int, int) -> int from the original feature request will be harder, since it's not valid syntax. Mypy and pyright have special parsing support for this, but ruff's parser (which we use for parsing) does not so we would have to upstream a change. That could be difficult, since Ruff doesn't appear to have plans to support type comments: https://github.com/astral-sh/ruff/issues/1619 (the thread also mentions that other tools like flake8 recently dropped support for this)
Given that this pattern is on the way out, my preference would still be to push libraries whose minimum supported version is >3.6 to switch to regular annotations. Some combination of https://github.com/facebook/pyrefly/issues/226 or inferring un-annotated attributes as Any would mitigate some of the noisiness from false-positive errors when we do encounter type comments (though it would not provide type safety).
Appendix:
Some more code examples:
variables (supports multiple targets):
x = [] # type: List[Employee]
x, y, z = [], [], [] # type: List[int], List[int], List[str]
x, y, z = [], [], [] # type: (List[int], List[int], List[str])
a, b, *c = range(5) # type: float, float, List[float]
x = [1, 2] # type: List[int]
with/for:
with frobnicate() as foo: # type: int
# Here foo is an int
...
for x, y in points: # type: float, float
# Here x and y are floats
...
for none-initialized variables checkers should not raise an error when the annotation does not match
from typing import IO
stream = None # type: IO[str]
Code pointers from other implementations
mypy
https://github.com/python/mypy/blob/81eaa5d1fb139d62418e16ee69d45b9c89ce46cb/mypy/fastparse.py#L1897
pyright
https://github.com/microsoft/pyright/blob/5f7ce347e8fbf80c826870b4a95395916cce3454/packages/pyright-internal/src/parser/parser.ts#L4853 (I believe there is a special parsing support for this non-standard function annotation syntax, and mypy probably has that as well)
Re: sentry, they just dropped 3.6 support last month, so I assume we'll have a version of the SDK with proper type annotations soon? There's a tracking issue here https://github.com/getsentry/sentry-python/issues/5008
Sentry just merged https://github.com/getsentry/sentry-python/pull/5206 to move away from type comments. I tried documenting the steps so others can follow - it was a pretty mechanical change that's easy to validate with mypy
