[fluster]

I view them as similar to python's "private" functions, which are really just functions starting with an underscore. The interpreter will let anyone call them like any other function, but the general rule is don't do it, unless you know what you're doing and are willing to deal with the internals changing.

Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need.

Do either of these things do anything comments couldn't? Not really. But they're ways of indicating intended semantics without formally documenting your stuff, and when most of what you use the language for is scripts, that's actually pretty helpful. People actually use type hints in a way they didn't with comments, and that's caused a major improvement in code readability. Or at least that's been my experience

You can absolutely look at all this and say python's a crazy, terrible language you never want to touch, but if you've got no choice on language for whatever reason, or you're throwing something together and don't feel like writing `private static final synchronized` forty time, type hints are great.

[the_af]

Thanks for your reply.

> I view them as similar to python's "private" functions, which are really just functions starting with an underscore

Good analogy! I wish they were more like "private" class methods, which are prefixed by a double underscore and result in name-mangling: you can still access them from outside if you want, but the code will really look ugly. And you absolutely cannot access them accidentally.

Which is what type checking should be all about, right? Preventing accidental misuse?

> Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need.

That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view. "These types are just something someone wrote, they may or may not accurately describe the code" seems so wasteful and unhelpful to me...

[uranusjr]

> That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view.

That’s the kind of the culture shock you get learning dynamic type languages with a static type pov. Type hinting is not really the problem here, but can seem that way because it makes dynamically typed code too superficially similar that it enters the uncanny valley if you treat it like statically typed.

One way that might make this easier is to forget about type hinting entirely at first and learn the language “from scratch”, and add the types back after you get used to write dynamically typed code. Dynamically typed code have its advantage and isn’t bad without type hints (well, at least you have to convince yourself on this, or you’ll never be able to learn a dynamic type language), and the type hints just add back some of the nice things static type provides without compromising dynamic type benefits.

[the_af]

Agreed, but it also clashes with the world view that brought us Typescript, which I also find better than Python's type hinting.

In addition, it makes it harder for me to argue in favor of type annotations with my coworkers. My coworkers come from neither world, static or dynamic; they are learning the ropes. And they just can't see the point. I'm confident I would convince them were this a statically typed language, but with Python I'm lost.

[uranusjr]

The TypeScript comparison is on an entirely different axis though, the compiled <-> interpreted one. One of the reasons languages go with the type hinting route is actually to avoid a separate compilation step like TypeScript. That may be totally fine for you (again coming from a statically typed language where this is more or less required), but it’s a hill many are willing to die on. It’s all tradeoffs and design decisions.

[the_af]

Agreed it's a different axis, that's why I said "also clashes". I of course think Typescript's choice in this tradeoff was the better one, even though I'm not particularly in love with Typescript either.

At some point everything in proglang is preferences and design decisions, but for me, there are better and worse tradeoffs to make.

[giyanani]

The typing (>= python 3.6?) and collections (>= python 3.8?) packages have definitions for a bunch of protocols (basically interfaces for structural typing).

So for that List[int] example, you probably want to take a(n) Iterable[int], Iterator[int], or Collection[int] instead, depending on exactly how you use it.

[spoils19]

> don't feel like writing `private static final synchronized` forty time, type hints are great.

We should think about whether there's a reason why we want to be writing `private static final synchronized` over and over again, after looking at the state of the software engineer these days.