this post was submitted on 14 Jun 2023
8 points (100.0% liked)

Python

6346 readers
3 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

📅 Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
💓 Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
 

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?

all 6 comments
sorted by: hot top controversial new old
[–] [email protected] 4 points 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.

[–] lightsecond 3 points 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.

[–] [email protected] 3 points 1 year ago

I don’t hate the idea. I feel like namedtuple works well enough. Maybe better effort could be making namedtuple behave more like a struct? Or some new type like frozennamedtuple?

[–] erez 3 points 1 year ago* (last edited 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):
      ...

[–] [email protected] 2 points 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)