On Tue, Sep 01, 2015 at 09:19:29PM +1000, Chris Angelico wrote:
On Tue, Sep 1, 2015 at 8:24 PM, Ian
wrote: mypy currently inspects the comment on the line of first assignment for the variables to be type hinted.
It is logical that at some time python language will add support to allow these type hints to move from comments to the code as has happened for 'def' signatures.
Potential problem: Function annotations are supported all the way back to Python 3.0, but any new syntax would be 3.6+ only. That's going to severely limit its value for quite some time. That doesn't mean new syntax can't be added (otherwise none ever would), but the bar is that much higher - you'll need an extremely compelling justification.
PEP 484 says: "No first-class syntax support for explicitly marking variables as being of a specific type is added by this PEP. To help with type inference in complex cases, a comment of the following format may be used: ..." https://www.python.org/dev/peps/pep-0484/ I recall that in the discussions prior to the PEP, I got the strong impression that Guido was open to the concept of annotating variables in principle, but didn't think it was very important (for the most part, the type checker should be able to infer the variable type), and he didn't want to delay the PEP for the sake of agreement on a variable declaration syntax when a simple comment will do the job. So in principle, if we agree that type declarations for variables should look like (let's say) `str s = some_function(arg)` then the syntax may be added in the future, but it's a low priority.
The other question is 'what about globals and nonlocals?'. Currently globals and nonlocals need a 'global' or 'nonlocal' statement to allow assignment, but what if these values are not assigned in scope?
Not sure what you're talking about here. If they're not assigned in this scope, then presumably they have the same value they had from some other scope.
But they will be assigned in the scope, otherwise there's no need to declare them global. def spam(*args): global eggs eggs = len(args) process(something, eggs) That's a case where the type-checker should be able to infer that eggs will be an int. But what if the type inference engine cannot work that out? The developer may choose to add a hint. eggs = len(args) # type:int will work according to PEP 484 (although, I guess that's a quality of implementation issue for the actual type checker). Or we could steal syntax from some other language and make it "official" that type checkers have to look at this: eggs:int # (Pascal, Swift, Ada, F#, Scala) int eggs # (Java, C, Perl6) eggs int # (Go) eggs as int # (RealBasic) Hence, for example: global eggs:int cheese:int, ham:str = 23, "foo" A big question would be, what runtime effect (if any) would this have? If the default Python compiler ignored the type hint at both compile-time and run-time, it would be hard to justify making it syntax. But perhaps the current namespace could get a magic variable __annotations__ = {name: hint} similar to the __annotations__ attribute of functions. Again, the default compiler would simply record the annotation and ignore it, the same as for functions, leaving any actual type-checking to third-party tools. [...]
Use of the 'local' keyword in the global namespace could indicate a value not accessible in other namespaces.
That won't work without a *major* change to Python's design. Currently, module namespaces are regular dicts, and there is no way to prevent others from looking up names in that dict/namespace. If you (Ian) want to change that, you should raise it as a completely separate PEP. -- Steve