Comments (16)
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):
x = [] # type: List[int]
# vs
x = Undefined(List[int])
x = []
Using cast()
is another option, but it's semantically different, since it can hide type errors (see #15).
If we absolutely decide that comments are a no-no, another option would be to define an additional helper that is similar to cast()
but that can't be used to hide type errors. It could be called coerce
, for example:
x = coerce(List[int], [])
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.
from typing.
I have to agree, and I don't see much value in forcing the type expression
to be evaluated at run time. So at least # type: comments should probably
be defined by the PEP.
from typing.
OK, will define # type
comments in the document.
from typing.
Fixed in e2e6fc4.
from typing.
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 coerce
idea, since Guido mentioned the problems with assert isinstance(…)
after the declaration.
or let’s at least use a string literal in the line above, which would appear in the AST!
'''type: List[int]'''
x = []
from typing.
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 __annotations__
attribute -- see PEP 3107). In this repo I have a partially-completed set of classes that implement the various generic and abstract constructs from PEP 483 and PEP 484 and you will find instances of those classes in the annotations.
In many cases you can actually write things like assert isinstance(x, Tuple[int, str, Callable[[int, str], Any]])
. But it's pretty slow, and I have no intention of making that code even more complex that it already is by trying to optimize it. Also, once implemented, assert isinstance(range(1000000), Sequence[int])
would instantiate a million integers and all check them. By comparison, the # type: ...
comments don't affect runtime performance at all. Function annotations affect runtime only during function definition time, which is usually during module load time, so their effect is much more tolerable.
from typing.
Also, most variable types (other than function arguments) will be inferred, so they won't be directly in the AST either. Implementing a type inference algorithm for Python is much harder than writing a parser that retains comments.
from typing.
Now, when you use argument annotations, they will be available at run time
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 assert isinstance(…)
let’s discuss other non-comment ideas instead!
one thing used by PyCharm is string literals:
'''type: List[int]'''
foo = []
or:
'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?
from typing.
Undefined
is also possible and already included in the PEP (clearly it's pretty verbose, but it seems pretty clear to me):
x = Undefined(List[int])
x = []
I mentioned this elsewhere; it's more efficient:
x = Undefined('List[int]')
x = []
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 # type:
comments).
from typing.
those are all ideas. feel free to add your own
from typing.
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.
from typing.
I like a lot the proposal from flying-sheep (for another PEP, I know):
foo: List[int] = []
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
from typing.
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.
from typing.
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
x = [] # type: List[int]
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,
x = Undefined(List[int])
is clearly intended for the interpreter and easier to discover since it's obvious what to grep for. (x = typing.Undefined(List[int])
is better, but that's up to the user.)
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.
from typing.
As discussed above, the # type:
comment syntax has benefits over Undefined(...)
: it's more concise in the common case of initializing a variable with an empty list or dict, and it doesn't add any runtime overhead.
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.
from typing.
Closing. Type comments are now in the PEP, and so is # type: ignore
.
from typing.
Related Issues (20)
- Clarify the implications of subclassing Any HOT 1
- Allow multiple `TypeVarTuple` in Generic Classes when they are wrapped. HOT 5
- pytype conformance tests crash if no `python3.11` executable is in `PATH` HOT 5
- Conformance test: make dataclass_hash.py not rely on `typing.Hashable`? HOT 1
- Proposal: Add coerced type narrowing similar to 'cast' HOT 1
- Idenity Type HOT 2
- [spec] clarify assert_type behavior as asserting type equivalence
- [spec] better clarify the difference between a runtime type object and a static type HOT 1
- [spec] a protocol type should be assignable to object? HOT 1
- [spec] define or replace the term "concrete type" HOT 1
- [spec] conceptual foundation and glossary entries for variance
- [spec] Overload processing order HOT 2
- Clarify signification of `Annotation` HOT 2
- A generic 'frame' type
- Enable Projects? HOT 5
- (🎁) `get_type_hints` should add the class to the locals HOT 4
- Conformance tests: PEP 702 HOT 1
- [spec] Clarification: Are symbols not listed in `__all__` ever considered public? HOT 1
- [spec] Formalize excluded Protocol members HOT 2
- Introduce an Unknown type HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typing.