I think misplaced # type: ... comments should be syntax errors. Internally, there have been several misplaced type comments that were ignored (a few mistakenly placed after a docstring, and one that had code inserted above it in a later commit), and I'd expect to see this continue to happen if we don't explicitly guard against it. It's pretty bad for these errors to be silent, because it means you think certain code is getting type checked when it really isn't. (And this can happen at a distance: e.g. you think calls to a certain function are being type checked, but they aren't anymore because some line was added before the type comment.)

I don't think the special case should be treated any differently, because I'd expect the typical case to look like this instead:

def foobar():
    # Some comment describing foobar or the type of foobar
    # type: () -> List[int]
    return []

In this case, we'd want to throw an error rather than be silent. Also, type comments are now (statically) semantically meaningful, so it doesn't feel too weird to me that they should have to be commented when used in a comment context, e.g.:

def foobar():
    # We can't turn on this type comment yet
    # # type: () -> List[int]
    return []

There's already precedent for double-comments like this:

x = 1  # type: int  # some comment about the type

In my mind, the existence of this construct furthers the feel of type comments as a distinct syntactic construct from normal comments (at least where PEP 484 type checkers are concerned).

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions