[Tutor] Should I use type hints for all new code?

[dn]

On 26/08/2023 02.03, Simon Connah via Tutor wrote:
> I'm wondering if I should use type hints for new code. They make things easier to read and they stop sloppy mistakes but do they have a performance impact?
> 
> I just want to know what is considered best practice these days.


Am reminded of 'Postel's Law' 
(https://en.wikipedia.org/wiki/Robustness_principle), ie being precise 
in what one writes, but accepting what you read.

Trouble is, once the Open-Closed Principle and the Single-Responsibility 
Principle or Separation of Concerns are added (to the above), a tension 
between them becomes evident - hence the word "law" being deprecated. 
Diving into OOP philosophy, polymorphism brings a whole extra layer to 
the mix.
(my brain is full - can I go home now?)


Remember that typing (and thus mypy, etc) is an 'add-on', rather than 
part of the Python language. It is not *necessary*. However, the OP 
lists *advantages*.


Perhaps less concerning than execution-time performance is 'developer 
efficacy'. Python-Masters are able to 'see' larger 'chunks' of code in 
their minds. Whereas, Apprentices have to concentrate to produce one 
line at a time.

If the addition of typing causes 'brain overload' and has the effect of 
reducing one's ability to code the series of statements necessary to 
complete a single task; then ignore them - or perhaps come back to add 
them later.

If one finds it part of 'design thinking' to consider the data-type as 
well as the name* of some new identifier, on top of keeping the 
necessary program-logic in-mind; then more power to your right arm...

* as often mentioned 'here', it is usually easier to name something when 
you come to 'use' it. Accordingly, don't stress over naming stuff at its 
first declaration, but re-consider its name when wanting to make use of 
it (and thank the 'PyCharm-gods' that they embedded refactoring/renaming 
operations within that IDE). If that rings-true for you, then the 
thought can probably be extended to typing...


Another way of looking at both typing and naming, is one's design 
approach. Many folk today follow a type-and-design process, encouraged 
by the mechanisms of an interpreter and the REPL. Accordingly, thinking 
with one's fingers (?).

Whereas, us old f***s were taught to design first, check/test next, and 
code last. Someone following a top-down technique such as this, has 
named many of the necessary components at the design-step - take a look 
at a UML class-diagram, as needed (eg 
https://i.pinimg.com/originals/d9/c3/e5/d9c3e593b86ec2294338cbc1fd97961d.png). 
Thus, there is 'spare' cognitive process to also consider the 
identifier's type. See also, database schema.


Final comment. As @Mats described. I try to use type-hints in all 
tutorial examples, or code which may be reviewed or maintained by 
Python-Apprentice colleagues. Even when the typing descriptions take-up 
more screen/slide space, they ease readability and thus learning. 
"Explicit is better than implicit"!

There again, dashing-off something for my own use might be an excuse to 
think differently. However, in increasing?decreasing decrepitude, my 
memory thanks typing in somewhat the same manner as ABCs (Abstract Base 
Classes) - a very handy aide-memoire preventing flawed assumptions 
(particularly when my current-self working on the code is what was once 
thought to be my self-in-six-months-time).

(as my English teacher liked to say: "assume" makes an "ass" out of "u" 
and "me" - upon which witticism I shall leave you (?reeling) )

-- 
Regards,
=dn