3 ms·

I do not see the benefit of type hints. Good docstrings (and naming of the function and arguments) are superior, at least for the human. Type hints are too much

• baq 4y ago
  There’s a certain program size from which they start to make sense and further still the benefits are obvious - you have a computer to help solve puzzles for you, so why not use it if the puzzle is ‘will this peg fit into that hole?’ when you have thousands of pegs and holes.
  • mharig 4y ago
    And so you end up writing climb_the_wooden_ladder(l: WoodenLadder) plus climb_the_aluminium_ladder(l: AluminiumLadder) or press all into an OO hierarchy instead of climb(thing): '''Climb a thing with steps''' # prevent run time crash: if not hasattr(thing, 'getSteps'): hitDeveloper()
    • baq 4y ago
      No, you define a Ladder (or Climbable if you’re feeling fancy today) Protocol and all remains good in the world.
    • cfu28 4y ago
      No need for OO hierarchy, just use a protocol
      • mharig 4y ago
        Oh, I missed the Protocol class of the typing module. Have to further investigate the usage of this. Thanks to you and baq!
• kbelder 4y ago
  I have a fear that Python will be improved to the point it offers no more advantage over other languages.
• jcparkyn 4y ago
  > type hints are too much clutter. Any sufficiently detailed python docstring contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a type annotation.
  • mharig 4y ago
    Which suits duck typing better than type hints.
• __MatrixMan__ 4y ago
  Docstrings are great until you change your mind about something fundamental. Once you make that big scary change you might have to rerun your unit tests dozens of times before you've found and fixed all of the bugs that your change caused. A static type checker, plus a bit of foresight and diligence, will give you a much more complete view of the carnage up front, so that you have a good idea about the cost of making that change while it's still cheap to decide differently. And the best part is that with python you can only bother with the type hints where you need them (e.g. at the boundaries between teams)
  • mharig 4y ago
    Never experienced that. Maybe you should make your code more modular.
    • __MatrixMan__ 4y ago
      I agree with you there. The experience I was thinking of here involved taking a codebase which wasn't modular enough and making it modular. So the "big scary change" involved changes to the module boundaries (which are the only thing I bother with type hints for anyhow).
• mmcnl 4y ago
  Docstrings won't tell you if your code is valid or not. Type hints with proper linting will. Shorter feedback loops = increased productivity.
  • mharig 4y ago
    Since I'm programming in Python, I experienced invalid code only in very few cases, more or less just where the function expected an iterable and I gave a string instead of a list of strings (typing errors are well prevented by the colour hints e.g. neovim gives with the right plugin). And some libraries sould be better documented. But the compile time error messages of C or C++ or Delphi most of the time do not deliver a shorter feedback loop, because they are generally ugly and hard to understand. And you should write tests in all languages, so static typing isn't a timesaver in that respect, too.