Python developers are embracing type hints

Post by pansa2 » Sun, Sep 28, 2025, 12:14 PM UTC

TZubiri wrote: post #287

Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

So the type is anything that implements the index function ([], or __getitem__), I thnink that's a Sequence, similar to Iterable. >from typing import Sequence >def third(something: Sequence): > return indexable[3] however if all you are doing is just iterate over the thing, what you actually need is an Iterable >from typing import Iterable >def average(something:Iterable): > for thing in something: > ... Statisticall…

Post by whilenot-dev » Sun, Sep 28, 2025, 12:21 PM UTC

thr0w4w4y1337 wrote: post #221

Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

from typing import Protocol, TypeVar T_co = TypeVar("T_co", covariant=True) class Indexable(Protocol[T_co]): def __getitem__(self, i: int) -> T_co: ... def f(x: Indexable[str]) -> None: print(x[0]) I am failing to format it proprely here, but you get the idea.

  from typing import Protocol, TypeVar
  
  T_co = TypeVar("T_co", covariant=True)
  
  class Indexable(Protocol[T_co]):
    def __getitem__(self, i: int) -> T_co: ...
  
  def f(x: Indexable[str]) -> None:
    print(x[0])

Post by totalhack » Sun, Sep 28, 2025, 12:27 PM UTC

Post by zx8080 » Sun, Sep 28, 2025, 12:48 PM UTC

kketch wrote: post #249

pansa2 wrote: post #241

Earlier quoted context omitted.

> They don’t violate the spirit of the language. They are optional. That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.

Well, precisely: - There is one obvious way to provide type hints for your code, it’s to use the typing module provided by the language which also provides syntax support for it. - You don’t have to use it because not all code has to be typed - You can use formatted strings, but you don’t have to - You can use comprehensions but you don’t have to - You can use async io, but you don’t have to. But it’s the one obvious…

Post by seanparsons » Sun, Sep 28, 2025, 12:57 PM UTC

pansa2 wrote: post #127

seanparsons wrote: post #110

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.

> all the popular dynamic languages have slowly become statically typed I’ve heard this before, but it’s not really true. Yes, maybe the majority of JavaScript code is now statically-typed, via Typescript. Some percentage of Python code is (I don’t know the numbers). But that’s about it. Very few people are using static typing in Ruby, Lua, Clojure, Julia, etc.