I feel like “the syntax for specifying type parameters still feels “bolted on” to Python” is really understating how bad the current “syntax” is. “syntax” is also a very generous description.
How would you improve it? The only obvious improvement to me is you should be able to write f(a, b: int) and have both arguments as int. I don’t know how it would look though.
one reason to have partially typed programs is progressively retrofitting existing code bases with type annotations, e.g. as part of python upgrades. going all the way is the best of course, but this is not always feasible. partial annotations can be a real help when isolating call sites of loosely typed functions, e.g. does this code deal only with (unicode) strings or also with bytes (binary)?
Curious how pythons type syntax works, the current generic type description looks as if you’re manipulating runtime data & a static analyzer just knows how to resolve these variables.
Are these type parameter objects available at runtime to inspect?
Yes, the type aliases, type variables, and all type annotations attached to other Python objects are available at runtime. Several popular libraries and frameworks use them – not to try to type-check, but to derive behaviors like validation and serialization.
The current wave of async Python web frameworks, for example, mostly are built around using type hints at runtime to indicate desired querystring or request-body values and to describe the shape of response data structures.
This also led to a bit of concern when it looked like the people writing type-oriented PEPs seemed to be completely unaware of this ecosystem and tried to push ahead with changes that would make it more difficult to obtain and work with the annotations at runtime.
the current generic type description looks as if you’re manipulating runtime data & a static analyzer just knows how to resolve these variables
There’s some interesting social/political undercurrents that lead to that, as well… There has historically been a contingent of the python community that was opposed, or at best indifferent, to the introduction of typing. Some combination of maintaining community harmony, the promise that typing remain optional, preserving backwards compatibility, and some other organizational and technical decisions seems to have created a pretty strong bias towards implementing typing features outside the interpreter, or with minimal impact on it when necessary. So reusing (maybe even abusing) existing syntactic forms for typing expressions has been largely favored over adding new syntax specific to typing and the necessary changes to the parser.
There has historically been a contingent of the python community that was opposed, or at best indifferent, to the introduction of typing.
There are plenty of people who like that Python is a dynamically-typed language, because we like writing and working in dynamically-typed languages and Python is a pretty good dynamically-typed language. Luckily, at least some of them are in a position to ensure that Python is not forced by static-typing advocates to become a purely statically-typed language.
The scoping rules for type variables are difficult to understand. Type variables are typically allocated within the global scope, but their semantic meaning is valid only when used within the context of a generic class, function, or type alias.
I will vouch for this being a pain point. I still struggle to get my head around it after several years.
I feel like “the syntax for specifying type parameters still feels “bolted on” to Python” is really understating how bad the current “syntax” is. “syntax” is also a very generous description.
How would you improve it? The only obvious improvement to me is you should be able to write
f(a, b: int)and have both arguments asint. I don’t know how it would look though.I mean this PEP seems to do a really good job of improving it?
presumably, olliej is talking about the syntax for specifying GENERIC type parameters, not the types of parameters. see the linked PEP for examples.
God no. Then i would be forced to mark the a as Any in a partially typed program.
I can’t imagine writing a partially typed program but, fair enough. RE the above replies I misread olliej’s comment because I was real tired.
one reason to have partially typed programs is progressively retrofitting existing code bases with type annotations, e.g. as part of python upgrades. going all the way is the best of course, but this is not always feasible. partial annotations can be a real help when isolating call sites of loosely typed functions, e.g. does this code deal only with (unicode) strings or also with bytes (binary)?
Adding to this: Some use typing mainly to aid the language server, not to type check.
Thank god. This has always been extremely confusing.
The one thing that suprised me was the type alias syntax:
It’s so weird and doesn’t ‘feel’ like Python, but it’s a great solution to a really annoying problem.
I like it! Although the feature I’m missing the most in types is the ability to denote a subclass of two (or more) types, i.e. specifying inheritance.
Curious how pythons type syntax works, the current generic type description looks as if you’re manipulating runtime data & a static analyzer just knows how to resolve these variables.
Are these type parameter objects available at runtime to inspect?
Yes, the type aliases, type variables, and all type annotations attached to other Python objects are available at runtime. Several popular libraries and frameworks use them – not to try to type-check, but to derive behaviors like validation and serialization.
The current wave of async Python web frameworks, for example, mostly are built around using type hints at runtime to indicate desired querystring or request-body values and to describe the shape of response data structures.
This also led to a bit of concern when it looked like the people writing type-oriented PEPs seemed to be completely unaware of this ecosystem and tried to push ahead with changes that would make it more difficult to obtain and work with the annotations at runtime.
Yes! They can be used for runtime validation, dispatch, etc.
I even wrote a library that does it: https://github.com/erezsh/runtype
Very cool!
There’s some interesting social/political undercurrents that lead to that, as well… There has historically been a contingent of the python community that was opposed, or at best indifferent, to the introduction of typing. Some combination of maintaining community harmony, the promise that typing remain optional, preserving backwards compatibility, and some other organizational and technical decisions seems to have created a pretty strong bias towards implementing typing features outside the interpreter, or with minimal impact on it when necessary. So reusing (maybe even abusing) existing syntactic forms for typing expressions has been largely favored over adding new syntax specific to typing and the necessary changes to the parser.
There are plenty of people who like that Python is a dynamically-typed language, because we like writing and working in dynamically-typed languages and Python is a pretty good dynamically-typed language. Luckily, at least some of them are in a position to ensure that Python is not forced by static-typing advocates to become a purely statically-typed language.
I will vouch for this being a pain point. I still struggle to get my head around it after several years.