[Python-ideas] ideas for type hints for variable: beyond comments
Ian
ian.team.python at gmail.com
Tue Sep 1 17:01:29 CEST 2015
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.
More information about the Python-ideas
mailing list