Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The use of comments to communicate with the type checker #35
mypy supports comments of the form
I ask: should we define such comments in the PEP or not?
referenced this issue
Jan 8, 2015
One of the most common cases in mypy code where annotations are needed is when creating an empty collection. I like it better with '# type:' comments (and mypy contributors seem to agree):
If we absolutely decide that comments are a no-no, another option would be to define an additional helper that is similar to
All of the non-comment alternatives have the problem that especially complex types can introduce non-trivial runtime overhead, which would go against the goals of mypy.
as said in the mailing list, please consider reopening this.
type annotations being available at runtime would be extremely useful for optimization purposes, and people will use it like that.
i like the
or let’s at least use a string literal in the line above, which would appear in the AST!
'''type: List[int]''' x = 
added a commit
Jan 17, 2015
This was referenced
Jan 17, 2015
I'm happy to reopen the discussion.
First, the use of annotations for optimization or code generation is explicitly out of scope for this PEP. (Optimizers like PyPy have shown that they don't need annotations.)
Now, when you use argument annotations, they will be available at run time (just inspect the
In many cases you can actually write things like
i know, but thanks for bringing my attention to this. runtime availability is of course even more easily accessible than literals only appearing in the AST. but this also makes the gap between significant comments and annotations even more apparent: one has language support and is available during runtime, the other isn’t even available to the interpreter after parsing.
about runtime costs: yes, you’re right, i’ll stop championing
let’s discuss other non-comment ideas instead!
one thing used by PyCharm is string literals:
'''type: List[int]''' foo = 
'type: List[int]' foo = 
the disadvantage is that it is more spacey compared to a comment.
this could be fixed using this style:
foo = ; 'type: List[int]'
or we could do something like this:
foo, * = , List[int]
or introduce explicit language support:
foo: List[int] = 
any other ideas?
I mentioned this elsewhere; it's more efficient:
Though clever, @flying-sheep's proposals above (except for the new syntax, which I like, but which will not happen in this PEP) look pretty difficult to read to me and inconsistent with the rest of the language (even more than the
After thinking it over and considering it some more, I still don't like the string literal proposal. So let's not waste more time discussing it (there are enough other things more worthy of our attention if we want this to land in 3.5).
PS. If you want a parser that preserves comments, there's one right in the Python standard library, in the lib2to3 package.
I like a lot the proposal from flying-sheep (for another PEP, I know):
It is consistent with many modern programming languages (Swift, Scala, Go, Typescript, Rust, Objeck, Julia, Nim/Nimrod...): Rationale behind the ordering of Scala's declaration. Yo can compare some of them at: http://rosettacode.org/wiki/Variables
Yeah, if this PEP is successful, we'll probably introduce some syntax close to that. However, for the current proposal the requirement is that we don't change the language's grammar; that way it will be easy for the typing module to be back-ported to Python 3.4 or earlier.
I'd like to argue against using comments to communicate with the type checker from another direction: conventionally comments are used by humans to communicate with other humans, not with machines. If someone reads
without context, it's not going to be clear that this is intended at least as much for the type-checker as it is for the reader, and it's going to be harder to find the associated syntax. Something like,
is clearly intended for the interpreter and easier to discover since it's obvious what to grep for. (
The flip side of this problem is that if there's type-hinting syntax in the comments, any program that wants to use the type-hinting is going to need its own tool chain to do so, starting with the parser and then proceeding up. There are lots of uses for typing out there that don't involve optimization these days, and making type information available programmatically from the start will ensure there's a unified API for typing-based extensions.
As discussed above, the
If type annotations really take off, it's likely that somebody will create a generic AST module that will know about the comment syntax. This is not very hard to do. Existing tools can migrate to use the new module to access the type comments. Hopefully it would have a mostly compatible API with existing parsers.
Also, IDEs and editors can implement special syntax highlighting rules for type comments (and string literal types) to make them stand out better.