`type: ignore` needs to be placed partway through a multi-line variable assigment in some cases

[timabbott]

Usually, mypy does this correctly, but today I had to merge zulip/zulip@c4716ae because mypy was throwingreporting an error (caused by an unrelated typeshed bug) that had been suppressed by that type: ignore, but stopped being when we line-wrapped the assignment.

We're using mypy 0.501.

[ilevkivskyi]

This looks quite similar to #3177, but probably not an exact duplicate. Here it is less clear what is the most obvious line for mypy to report an error. I think the current behaviour is OK. Maybe we should just document some rules for line numbers in errors in multi-line statements/expressions?

[JukkaL]

Yeah, this is a known issue, and doesn't just affect assignments. Do you have a specific improvement in mind? It's not obvious to me what would a generally better way to do this.

[gvanrossum]

I think it's different from #3177. That issue is specifically about everything related to a function heading being attributed to the line where the first decorator starts.

This issue is about whether the scope of a type-ignore on a statement that's split across multiple lines should be the entire statement rather than the specific line number on which the type-ignore occurs. I think it's an implementation weakness but it may be hard to fix, since AFAIK the typed_ast parser just gives us line numbers for type-ignores (rather than working them into the parse tree).

Either typed_ast or mypy would need a significant re-architecting of the code around type-ignores to fulfill this wish. Also, sometimes it's a useful feature, e.g. when you have a long list of expressions like this:

handlers = [
    foo,
    bar,  # type: ignore # There's something funny about bar
    baz,
]

@ddfisher ^^

[ddfisher]

AFAIK the typed_ast parser just gives us line numbers for type-ignores (rather than working them into the parse tree)

Yeah, that's the current behavior. That's because type ignores don't really fit into the parse tree in a particularly sensible way -- they're valid anywhere. If this is something we want to fix, changing that is probably not the way forward -- I think it'd be easier to understand the start and end points of statements, and filter errors that way.

[brandtbucher]

#6648 fixed this, I think. At least for Python 3.8.

[gvanrossum]

Yup!