4 ms·

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 m

• kingofthehill98 4y ago
  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.
  • theLiminator 4y ago
    Definitely disagree, especially not the case for function arguments. Having no types in the arguments makes an api incredibly hard to use.
  • alanwreath 4y ago
    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 https://m.youtube.com/watch?v=xvb5hGLoK0A
• baq 4y ago
  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.
• hitchdev 4y ago
  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)"
• wittekm 4y ago
  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!
  • kristianp 4y ago
    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.
    • dragonwriter 4y ago
      > 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.
  • Paul-Craft 4y ago
    Oh boy. A million-line monolith.... Does this company name start with a 'Y' by any chance?
    • shortcake27 4y ago
      Many people like working on monoliths. Let people enjoy things.
  • KeplerBoy 4y ago
    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.
• sampo 4y ago
  > 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.
  • pharmakom 4y ago
    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.
• peteradio 4y ago
  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.
• wffurr 4y ago
  No. Types make the function signatures clear and obvious. If the types are really complicated, then the function probably is too.
  • dragonwriter 4y ago
    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.
• maccard 4y ago
  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.
  • zelphirkalt 4y ago
    Where is the improvement compared to code, that properly names arguments instead?
    • dragonwriter 4y ago
      The improvement is, among other things, in IDE tooling.
  • im3w1l 4y ago
    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)
    • maccard 4y ago
      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! vs 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?
• mjw1007 4y ago
  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.
• massysett 4y ago
  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.
• zelphirkalt 4y ago
  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.)
  • gugagore 4y ago
    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.
    • extasia 4y ago
      Factory pattern is still used in Python, for example in the popular huggingface library, Transformers.