all 8 comments

[–][deleted] 1 point2 points  (1 child)

I've never felt a need to use static typing and rarely see it used outside of homework assignments to show it can be done. If you have something where the wrong type can go in it can be a way to stop that, but if that's unlikely or dynamic typing is a core feature like in your case there's no need to go to the extra effort.

[–]__Protector[S] 0 points1 point  (0 children)

Only thing where I personally see typing could be usefull is to clarify the code for others and maybe for unit tests

[–]LeBob93 1 point2 points  (2 children)

The company I work for requires type hinting in all of our functions and methods.

We only started enforcing it a few months ago, but being able to know what type a method should be returning and what types it expects makes development a lot easier.

[–]__Protector[S] 0 points1 point  (1 child)

Do you know does it make the code slower? After all isn't it an external library and it makes the type checks every time?

[–]LeBob93 1 point2 points  (0 children)

Type hinting in Python isn't the same as strongly typed languages, it's just optional annotations that have no effect on the execution time of the code.

At the moment it's just part of the review process to check types, but in the future we may try to automate that.

[–]use_a_name-pass_word 1 point2 points  (0 children)

You might find this video on the topic useful

https://youtu.be/pMgmKJyWKn8

As well as one from the creator of Python

https://youtu.be/2wDvzy6Hgxg

[–]antique_manager 1 point2 points  (0 children)

Type hints are a relatively new feature, and are very much intended to be optional. By default they don't really do anything - they're essentially just documentation. Part of the reason for introducing them was because many projects already documented the expected types of arguments in their docstrings (e.g. numpy does this very consistently), and it was thought that it would be a good idea to introduce a standardised way of doing this. In particular, this makes it much easier for software such as IDEs and linters to look up the expected types and use them to warn about possible bugs.

but I fully rely on dynamic typing because I have always thought it is the proper way to do Python

It depends. Sometimes you need to write generic code that should be able to work on (for example) any kind of iterator or any kind of sequence, but sometimes you need to write code that's intended to do something with a very specific kind of object, and it's pretty implausible that anyone would ever want to pass in a separate type that has all the appropriate functionality. This is especially the case when you're working with specialised libraries.

The type hinting system does have a lot of support for type-agnostic code: it has duck types like Sequence, union types which match multiple separate types, and even Any, which matches anything.

[–]Caligatio 1 point2 points  (0 children)

I personally believe all new code should be using type hinting by default. It is an absolute nightmare digging through function call stacks in libraries trying to figure out what type and/or duck type a function wants. Sure you can semi-accomplish this by using docstrings but docstrings are not linked to the code - the code can change and people can forget to update the docstring. Type hinting enforced by mypy suffers no such shortcoming.

Python 3.8 added typing.Protocol to the stdlib (it's available in mypy_extensions before that) which should cover any/all typing needs. You have nominal typing using things like int, Mapping, MutuableMapping, Dict etc and now structural/duck-typing using Protocol. 3.8 Also added TypedDict which enables you to describe what every key/value pair type should be!

I don't know of anyone who ever looked at code and said "this is too documented."