Python’s “type hints” are a bit of a disappointment to me

Re:Python’s “type hints” are a bit of a disappointment to me by wheelerof4te on Friday April 22, 2022 @09:44AM (#31121431)

How is typing productive in large codebases? If I see a bunch of imports related to typing only, I have to juggle them around in my mind together with stuff that really matters.

Not to mention the notorious circular import problem, that is much more likely in a big codebase.

If I have a custom class, that class has to be passed as a type hint for functions. What If I use that class in another module, but have to import it inside this one that has a type-hint only?

Well, let me introduce you to their genious solution:

  from _future_ import annotations
  from foomod import FooClass

  def myfun(foo: FooClass):
    return foo.bar()

Wonderful, isn't it?

[ Parent | on HN ]

Re:Python’s “type hints” are a bit of a disappointment to me by icedchai on Friday April 22, 2022 @06:20PM (#31128923)

I also find most of the "import typing" stuff to be clutter. I worked at a place that was heavily into adding typing to existing code, some of which was almost a decade old. They spent more than a few person years on that effort, and it's still going on.

Not once did I find the additional typing useful in my actual day-to-day work.

[ Parent | on HN ]

Re:Python’s “type hints” are a bit of a disappointment to me by bayesian_horse on Saturday April 23, 2022 @12:30AM (#31131409)

Scaling a code base doesn't start or end with type checking. Some of the answers to what you are implying is: Use interfaces when using OOP. Consider dependency injection or other Inversion of Control patterns. Maybe don't use OOP as much...

[ Parent | on HN ]