I’m still digesting this one and haven’t formed any strong opinions yet.

I’ve had problems in the past where this could have been useful, like ingesting millions of lat/long positions and trying to string them together in a “trail”. But, I was still able to handle that fine with namedtuple without too much pain.

Thoughts?

  • NullNowhere@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    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.

  • erez@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    1 year ago

    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):
          ...
    
    
  • DanCardin@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    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)

  • lightsecond@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    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.