Make your Python functions return something meaningful, typed, and safe

I tend to agree, Python really shines when it's just being Python.

I only typehint certain parts of the code where i find it usefull. Typehinting everything makes Python code really hard to read IMO.

mypy and Python typing have really only picked up pace once Typescript has shown that it can be done, and well. Typescript also doesn't give any runtime safety but the compile time safety gains are very much worth it. There is no reason Python + mypy couldn't get the same guarantees when you keep to the less adventurous parts of it.

They are useful if you program in a somewhat object oriented way. They are deeply unhelpful if they're all either "method(self) -> dict" or "method(input: pd.DataFrame)"

Having worked at a company with a million-lines-plus of Python monolith, gradual typing annotations made all the difference. Why do you need it enforced at runtime? It's static types!

> I find that if I want type safety, I'd rather branch out to other languages that were designed for it from the start.

Those other languages don't have pandas, scikit-learn, pytorch. If you are building on top of Python's data science and machine learning ecosystem, it's nice to have both the wide range of libraries available in Python, and type safety. Even if the annotations get a bit ugly looking.

Annotations can come in after you've cracked the architecture. Once you are in that place you really shouldn't be getting bothered by the annotation because you are building on top of them and its helping your code completion.

No. Types make the function signatures clear and obvious.

If the types are really complicated, then the function probably is too.

Definitely just you.

    def calculate_points(word: str) -> int:
        guessed_letters_count = len([letter for letter in word if letter != '.'])
        return _award_points_for_letters(guessed_letters_count)

    def _award_points_for_letters(guessed: int) -> int:
        return 0 if guessed < 5 else guessed  # minimum 6 points possible!

this is an enormous improvement.

For readability, I'd quite like to see a design that looks a bit more like K&R-era C, where the function signature just has the parameter names, and each parameter's type annotation gets a line of its own somewhere further down.

Try Common Lisp. Unless you tell it otherwise, Steel Bank Common Lisp treats all type declarations as assertions. They are checked at runtime. The compiler also does a great deal of compile-time checking too.

But if you don’t like to use any of it you don’t have to. So you can annotate just some code, either because you want the types checked or for performance reasons.

One caveat though: SBCL’s treatment of type declarations in this manner is implementation specific (well, SBCL’s predecessor, CMUCL, also did this.) The Common Lisp standard simply says the result is undefined if a value’s type does not match the declaration. So a more portable way to do this is to use the CHECK-TYPE macro and use declarations only for performance reasons.

I draw the line, when satisfying the type checker requires writing ugly uselessly complicated code, like writing classes just to use them as type annotations, because the type checker does not get it otherwise, and things like that. Things that introduce code inflexibility at a later point, or encourage bad designs of using too much inheritance. Writing type annotations for procedure arguments and return type can be quite helpful. I just don't want to overdo it all. If the tradeoff is that far into the safety direction, then why did anyone choose Python for that project and not say for example Rust? Or even Java?

Lets not make Python the new Java. People already start to translate design patterns 1 to 1 from Java examples to Python and I have to tell them, that there are other ways in Python. Lets not choke Python programs with design patterns that are needlessly implemented in complicated ways, where the language already provides other means! (singleton, visitor, factory, decorators, etc.)

Imperative styles like yours are readable, and more importantly, hackable.

Business processes are rarely set in stone and the above code can be easily modified, as opposed to a "beautiful" "pure" "correct" ball of functional yarn that must be carefully unwound and rearchitected.

Yes, it's not pythonic.

But the Maybe monad does have its beauty, which the in-built Optional doesn't really provide. If this package makes people more accepting, then let them.

I don't even like that, since raising TypeError("args are not integers") would be easily more appropriate here, and arguably more pythonic.

In your example it should be

def add_ints(a: int, b: int) -> Tuple[int | None, bool].

I’m not a fan of the Tuple return type. This is how golang does things and while it works there I don’t like seeing this in Python code because the Tuple tells you nothing unless you follow this convention and you have to add the Tuple annotation on top of every return type making it harder to read. I don’t see a need for it here since you’re already returning an Optional[int] (int | None in Python 3.10+). You could also raise a TypeError. Also your type checker should catch this if a or b are not an int, so you might feel safe returning a+b at this point and having the return type be simply int.

Agreed. Can't count the num of times I've wished Python had real lambdas.

Python is deeply incompatible with this style. No do-notation, crippled lambdas, slow function calls. If you want to write Rust/OCaml maybe use Rust or OCaml?

seems you can now sort of write Scala in Python

I really don't.

Raise a `NotFound` exception in the method and catch that instead when you're calling...

Just use SML (Standard ML)?