Opinion: This doesn’t really solve a problem like dataclasses v. namedtuples did. This mostly boils down to someone not really liking the dataclass syntax and deciding that adding yet another way to write classes is the way to go and is somehow more teachable (because now we need to teach both).

Maybe it’d be nicer in a few use cases, but I don’t really feel it’s worth the expansion to the syntax burden.

I agree with the article that dataclasses and namedtuples aren’t as good as they can be. But I think the solution should be to make dataclasses native, and not namedtuples.

So we could write something like:

dataclass Point:
  x: int   @"why not also add new syntax for documentation?"
  y: int   @"the size of translation on the Y axis"

  def methods_as_usual(self):
      ...

I wouldnt hate its existence, and certainly i would always prefer anyone use this over namedtuple.

At the same time, i think i would never use it. 90% of my classes these days are dataclasses, and the set that don’t inherit from anything, and have no methods are vanishingly small

I don’t know that harkening to rust structs makes much sense in python, (…which can have methods)

I’m not a fan of introducing yet another “type of class”.

In my humble opinion, if we do introduce rust-like match it should work on top of the existing concepts of dataclass, namedtuples, and union-types to avoid confusion on when to use which mechanism.

Also, type hints aren’t compulsory, but they are so damn useful that I’d be okay if some features only worked when the original variables had type hints.

Ah, I don’t know, maybe just use PyO3 and compile your Rust code into Python libraries /s