You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In mypy there are two ways to annotate a variable: with a # type: comment or a cast expression. The following are equivalent from mypy's POV:
result = [] # type: List[int]
result = List[int]()
Each has its disadvantages:
Jython's parser doesn't preserve comments and they don't want to change the parser
The cast expression incurs significant overhead (List[int] creates a new parametrize type object)
There's no clear solution at this point; something has got to give (though the PEP should probably support both and point out the issues).
For some specific cases (e.g. a variable initialized to an empty concrete container that is used directly in a 'return' statement) we may be able to improve the type inferencer, but in general that's a path we would rather not take (there's a good reason we start with function annotations only).
In the future (e.g. Python 3.6 or later) we may be confident enough to introduce variable annotations, e.g.
var result: List[int] = []
or perhaps even
result: List[int] = []
But this remains to be seen, and we definitely don't want to do this for the current PEP or Python 3.5. Plus, it might still incur exactly the same runtime overhead.
Another option (discussed at our in-person meeting) would be to support # type: comments but give them a lesser status (e.g. "hint") so implementations can ignore them and still be conformant. It's not entirely clear what this would mean -- if the implementation concludes there is a problem because it can't see the comments, is it allowed to issue an error?
I dislike advertising instantiation of typing.List objects because:
it suggests that it's okay to do so for all other typing constructs. Counter-example: TypeVar is special and cannot be freely assigned.
it is yet another way to do it (e.g. newbies will start doing l = List())
Also, if we decide to support registration of alternative implementations (see #7), we need to make sure we don't initialize any typing.List before the registration is done.
As for treating comments as lesser status, I don't think it's pragmatic. The entire reason behind the comments is that otherwise it's impossible to infer the type in time for static analysis.
Agreed -- let's just make List() and List[int]() fail. Depending on whether we endorse # type: ... comments, we can recommend these alternatives (even if they don't always mean exactly the same thing):
x = [] # type: List[int]
x = Undefined(List[int]); x = []
x = cast(List[int], [])
Activity
gvanrossum commentedon Oct 16, 2014
Another option (discussed at our in-person meeting) would be to support
# type:comments but give them a lesser status (e.g. "hint") so implementations can ignore them and still be conformant. It's not entirely clear what this would mean -- if the implementation concludes there is a problem because it can't see the comments, is it allowed to issue an error?ambv commentedon Jan 7, 2015
I dislike advertising instantiation of typing.List objects because:
l = List())Also, if we decide to support registration of alternative implementations (see #7), we need to make sure we don't initialize any typing.List before the registration is done.
As for treating comments as lesser status, I don't think it's pragmatic. The entire reason behind the comments is that otherwise it's impossible to infer the type in time for static analysis.
gvanrossum commentedon Jan 7, 2015
Agreed -- let's just make
List()andList[int]()fail. Depending on whether we endorse# type: ...comments, we can recommend these alternatives (even if they don't always mean exactly the same thing):gvanrossum commentedon Jan 7, 2015
PS: I filed python/mypy#551 -- it seems mypy doesn't flag returning an undefined value as error.
ambv commentedon Jan 8, 2015
I like using cast() and Undefined in that case. This is exactly what we would want to provide special syntax for in Python 3.6.
Will update the PEP accordingly.
gvanrossum commentedon Jan 8, 2015
Actually, I think the version using a type comment --
x = [] # type: List[int]-- should be recommended now that we're endorsing type comments. (#35).ambv commentedon Jan 14, 2015
castis not introduced in the PEP yet.ambv commentedon Jan 14, 2015
But the issue is solved in e2e6fc4.