Hacker News Reader

Comment by tremon | Hacker News Reader

Is it just me or do more people find that Python is becoming more and more illegible with these type annotations? I understand why they are introduced, but to me they cause a lot of line noise in the relatively clean signal that is Python code.

To add insult to injury, type hints are not enforced nor even verified by the runtime. I find that if I want type safety, I'd rather branch out to other languages that were designed for it from the start. In particular, I find that rewriting some of my Python modules in Rust is a joy (using PyO3, but keenly following RustPython development too).

View on HN

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!

They said "by the runtime", perhaps they mean that the python interpreter should throw errors at compilation time, since its not a classic compiled language.

> They said "by the runtime", perhaps they mean that the python interpreter should throw errors at compilation time, since its not a classic compiled language.

Why waste time doing static analysis each time you run the code? If you don't change the code, its not going to change.

Oh boy. A million-line monolith.... Does this company name start with a 'Y' by any chance?

Many people like working on monoliths. Let people enjoy things.

Because the type annotations are worthless if you can't ever be certain that they actually hold.

Currently they are little more than a crutch to have intellisense working.

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.)

The factory pattern in Java exists because a type / a class is not a "first-class" concept. You can't pass around a class so that it gets constructed at some other point. Python (which I believe inherits from Smalltalk) has a different object system, which makes the factory pattern irrelevant.

Factory pattern is still used in Python, for example in the popular huggingface library, Transformers.

> 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.

Pretty sure they do, actually. All of those libraries have C bindings, a Rust alternative (e.g. Polars) or are actually implemented in Rust anyways.

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.

Where is the improvement compared to code, that properly names arguments instead?

The improvement is, among other things, in IDE tooling.

My eyes start glazing a bit from the strain of checking whether the variable names match or not. I prefer

    def calculate_points(word: str) -> int:
        count = sum(x != '.' for x in word)
        return _award_points_for_letters(count)

I think that's unrelated to the type annotations though. Using the other function:

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

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

is "guessed" letters or is it the number guessed?

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.

Definitely disagree, especially not the case for function arguments. Having no types in the arguments makes an api incredibly hard to use.

You can slap out the POC without types for sure - but the addition of types helps

  - tests fail faster
  - code documentation
  - IDE’s complain better
  - teams collaborate better

It becomes more helpful as projects and teams mature.

I’d say that types aren’t the last step though, I’m starting to prefer protocols and those are proving to be even more loosely coupled and more pythonic to me. They let you “type” the behavior rather than the actual type. Say there is a case when you don’t care if it’s a set, tuple, or a list because all you’re going to do is Iterate, we’ll you’d go the behavior route and say you want an Iterator. You can create your own protocols as well and it has the effect that you document what you intend to do with the objects passed to you such that it doesn’t matter what you pass as long as it adheres to the protocol you defined. It’s documented duck typing. Here’s a great video that explains how it can simplify your code https://m.youtube.com/watch?v=xvb5hGLoK0A

No. Types make the function signatures clear and obvious.

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

If the types are really complicated and the function isn’t doing too many unrelated things, you probably want to define some types or aliases.

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.

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.

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.

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.

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)"

Reply on news.ycombinator.com