Chris Angelico wrote: " > 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. " My intent must not have been clear. I am not suggesting changing function annotations. I think function annotations as they are represent an addition that has been well thought out and is a very useful step which extends what is possible in a very useful way. Pep 484 as introduced in 3.5 allows this to be taken further. I am suggesting building on PEP 484 with a complimentary extensions for variables. If extensions are made in the same manner as function annotations, then the actual python code simply has hints added. Generating warnings or other steps is the domain of separate off-line checkers. I feel it is clear that at some time an extension to allow type-hints for variables, complimenting current function annotations will be added. I am just providing food for thought on how annotations for variables can be added.

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. You shouldn't need to declare that "len" is a function, inside every function that calls it. Any type hints should go where it's assigned, and nowhere else. " These are hints. Not a 'need'. The type hints may be desired in the code referencing the 'globals' or 'nonlocals', but not desired in the original context. The idea is to allow this, NOT to require or need a declaration. Hope this helps clarify what I am trying to suggest.

What if we allowed global i:int

or

nonlocal i:int

and even

local i:int

Permitting a new keyword 'local' to me might bring far more symmetry between different cases.

Hey, if you want C, you know where to find it :)

Use of the 'local' keyword in the global namespace could indicate a value not accessible in other namespaces.

"I'm not sure what "not accessible" would mean. If someone imports your module, s/he gains access to all your globals. Do you mean that it's "not intended for external access" (normally notated with a single leading underscore)? Or is this a new feature - some way of preventing other modules from using these? That might be useful, but that's a completely separate proposal. " Good point, the single _already does what I was thinking. I never think of using it in this specific case. I tend to associate it with hinting that an identifier is for internal use within a class. Not to get warnings about use from outside the global namespace of globals.

Personally I would like to go even further and allow some syntax to allow (or disable) flagging the use of new variables without type hinting as possible typos

"If you're serious about wanting all your variables to be declared, then I think you want a language other than Python. There are such languages around (and maybe even compiling to Python byte-code, I'm not sure), but Python isn't built that way. Type hinting is NOT variable declaration, and never will be. (Though that's famous last words, I know, and I'm not the BDFL or even anywhere close to that. If someone pulls up this email in ten years and laughs in my face, so be it. It'd not be the first time I've been utterly confidently wrong!) " No, I am not serious about wanting all variables to be declared under normal circumstances. Again, as you say, this is about hinting and getting warnings. I think there are circumstances where hinting may be sufficiently useful that getting a warning for a missing hint would be desirable. This is not a suggestion to change python. But a suggestion to allow for specific situations without a change of how things normally happen. Thank you for taking the time to comment. It is appreciated and I hope I have been able to use your feedback to clarify.