Do we want to talk about type annotations in expressive code?

[sneakers-the-rat]

I can never find the blogpost when i need it but it has been argued that basically untyped and type hinted python are diverging into two separable dialects with different coding norms and practices. I am firmly in the "type annotations all day every day" camp because i love them, and i feel like they are pretty squarely in the core of what one might think of as 'expressive python.'

So thinking about this lesson: https://github.com/pyOpenSci/lessons/blob/main/clean-modular-code/activity-3/clean-code-activity-3.md

Part 2 is about mismatches in argument type, right.

the function here:

lessons/activity-solutions/part-3/part-3.py

Line 78 in ac58771

def process_published_date(date_parts):

should have a function signature like

def process_published_date(date_parts: list[list[int]]) -> pd.Timestamp: ...

and the value of introducing that idea is that you would indicate to someone who was calling your function that their arguments might be incorrect before they even try to call the function.

Type hints also propagate, so if you had

def inner_function(date_parts: list[list[int]]) -> pd.Timestamp:
    return process_published_date(date_parts)

def outer_function(year: int, month: int, day: int) -> pd.Timestamp:
    return inner_function([[year, month, day]])

def third_function(parts_again: list[list[int]]) -> pd.Timestamp:
    parts = parts_again[0]
    return outer_function(parts[0], parts[1], parts[2])


third_function(['hey', 'sup'])

then you'd be told from a long distance that your arguments are wrong and you can correct the problem without needing to dig deep into a call stack to see what's actually causing the problem. practically, that translates to all the code that needs to use your code being easier to use and less error prone.

I think for the sake of a beginner lesson just showing them the base types int, float, list[T], tuple[T, U, ...] + maybe dataclasses would be enough. I'd be happy to write it.

[willingc]

I think that I would cover #46 and #45 in a more advanced lesson on "expressive code". Though great topics, they are likely too much cognitive load for a person new to Python.

[sneakers-the-rat]

definitely an "after you've written a function or two" lesson. agreed.