Since static typing is available in Python 3.6, is it possible to force static typing for a Python project or set of Python files?
New in version 3.5. The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc.
Python will always remain a dynamically typed language. However, PEP 484 introduced type hints, which make it possible to also do static type checking of Python code. Unlike how types work in most other statically typed languages, type hints by themselves don't cause Python to enforce types.
In general, statically typed languages will execute faster than dynamically typed ones because their type systems are implemented at compile-time rather than run-time, so all the work involved is performed once only.
Python does not enforce the type hints. You can still change types at will in Python because of this. However some integrated development environments, such as PyCharm, support type hinting and will highlight typing errors. You can also use a tool called Mypy to check your typing for you.
You can use annotations
in Python3, which might help you get some benefits of static typing.
However if static typing were to be completely enforced in Python, then it won't be Python anymore. It's a duck-typed dynamic language, and would loose all dynamism as a result. If you really intend to use a statically-typed language, you are better off not using Python.
I think you cannot force static typing but you can use a checker as mypy
.
According to line 2 of The Zen of Python by Tim Peters, you have "Explicit is better than implicit." Static typing is a good thing, but "Simple is better than complex." ...
$ python3.6
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With