Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should a misplaced # type: comment be an error? #210

Closed
gvanrossum opened this issue May 1, 2016 · 4 comments
Closed

Should a misplaced # type: comment be an error? #210

gvanrossum opened this issue May 1, 2016 · 4 comments

Comments

@gvanrossum
Copy link
Member

Discuss. This becomes somewhat important since we're introducing a new, faster parser in mypy that treats them as syntax errors. @ddfisher

@gvanrossum
Copy link
Member Author

There's a special case that I'd like to discuss too: what if the misplaced # type: comment is part of a longer comment? Maybe something like

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

@ddfisher
Copy link

ddfisher commented May 1, 2016

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).

@gvanrossum
Copy link
Member Author

gvanrossum commented May 1, 2016 via email

@ddfisher
Copy link

ddfisher commented May 1, 2016

That sounds like a good approach to me!

@gvanrossum gvanrossum modified the milestone: PEP 484 finalization Aug 26, 2016
gvanrossum pushed a commit to python/peps that referenced this issue Nov 6, 2016
…heckers (#133)

Fixes python/typing#210.

This behaviour with --fast-parser is in mypy since mid-May. It looks like nobody is complaining.
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

No branches or pull requests

2 participants