Type annotations are not checked by Python. The language allows you to add annotations but Python itself doesn’t do any enforcements so they aren’t “part” of the language in many respects. They aren’t checked by the test runner. They don’t have any impact on the exercise solution and tests. They’re also not a beginner topic. As such, they are intentionally not included in the exercises.
Yeah, but type information is still included into every(almost) docstring so I though it might be a good idea to do it properly so students can get a glimpse of how modern python code looks like and later when there will be a Typing concept exercise for Python it won’t come as a surprise for them that Python had a nice syntax for type annotation all that time. And who knows maybe later Exercism team could switch on type checking as a part of automated feedback.
TL;DR: I though it would be a great addition to the Python track and if Exercism team is open for that I could volunteer to implement it.
Plenty of projects do types in docstrings. The current is correct, too.
This may or may not happen. If it does happen, there may be a decision to update other exercises with type annotations. Or not. The exercises often are meant to focus on specific topics. Enforcing or even introducing type annotations can distract from that. When the types are complicated or people aren’t familiar, they can over shadow the rest of the exercise in a way which takes away from what is supposed to be the focus.
Personally, I already use annotations. I think they are great. I often suggest people look into them as part of my mentoring sessions. Type annotations were previously discussed and considered. And a decision has been made. It might change in the future, but at the moment, that is the current decision.
Arguably, it should be polymorphic instead of monomorphic over int. Last time I tried that (context) with mypy there was only fairly new and experimental support for such types.
However, such a polymorphic type would be a tad wrong: the type variable could be instantiated at a list type, in which case the type signature would be a lie. Maybe this can be prevented somehow; I don’t know.
Yes, typing is not the issue here. At the end of the day it is just a bunch of names. It is up to the type checker to give meaning to these names. Various type checkers use various, incompatible type systems.
I do not expect it to matter a lot, by the way. Most problems on the platform are rather tame, types-wise.
I found/find Python’s annotations annoyingly noisy, but now it seems that the following is allowed (by mypy), which seems like a significant improvement:
My only suggestion was to move type annotations from doctrings to the function signature. When I’ve started the python track I was so unused to unannoted code, some of the useful features of the modern language servers(which I’ve learnt to rely on) suddenly stopped working and I thought it is the area for improvement.
Today I showed a mentored student a snippet of code which contained a type annotated function signature and he sad he does not understand it. Now I get Isaac’s point but it could also be because he was not aware of this feature from the beginning. Perhaps if he had been shown only type annotated code from the start his perspective would be different.