Skip to content

Comment on Python classes aren’t always the best solution

Comments

Wow, that is an impressively uninsightful article.

Apart from the first option, all of those are really obviously not classes.

The first option is a suggestion to use named tuples or dataclasses. That is sensible, but you are using a class in that case – those are just helpers for making them. You can even add your own methods to dataclasses.

For named tuples, you are better off using the typed version typing.NamedTuple [1] instead of the classical one suggested in the article. Aside from providing typing, the typed version has a much nicer syntax to define it and lets you add methods (like dataclasses but unlike classical named tuples)

[1] https://docs.python.org/3/library/typing.html#typing.NamedTu...

Sorry to pile on (to https://news.ycombinator.com/item?id=44676030), but can you please make your substantive points without putting others down, or their work? It's always possible to do so, and much more in keeping with the spirit we want here: https://news.ycombinator.com/newsguidelines.html.

It's great if you know more than others and have time to share some of what you know in the comments. But the putdown aspect is unnecessary and can really hit people hard sometimes.

Fair point. Sorry.

In my defence, vacuous articles are sometimes posted here and sometimes (rarely) reach the front page. I can see from other comments that this post doesn't count. I like to I think I got mixed up, not because I've forgotten what it's like to be a beginner, but because I started with procedural languages before purely class-based ones like Java.

Thanks, @dang

Chill, people are learning and not everyone has the luxury of reading the manual or going to school or using Python at work or whatever.

There is harmful advice in this article. "Just chill and use a dict or a namedtuple" leads inexorably to buggy code.

The advice to use dataclasses is good but... dataclasses are, um, classes.

I thought readers would understand that an alternative to a class just meant you don't have to create one from scratch. Maybe not.

dataclasses are, um, classes

So is the case when you use `namedtuple`, which creates a new class. This is not an interesting gotcha.

Classes (the Python language construct) are how you implement records (the language-neutral concept) in Python.

It's ironic that the "There Is Only One Way to Do It" language has multiple bad ways to implement records though.

Are people really making classes with a single static method and nothing else? It just feels like filler material.

Yes. They probably learned Java first.

+1. I learned Java first, in school and on my own. I needed to unlearn the OOP-first mindset.

This has nothing to do with OOP. A class with a single static method isn't OOP

You can use the 'class' keyword and write your program functionally, or procedurally

So you actually thought you needed, in Python, classes with static methods instead of just plain old modules? What was your first Python "hello world" like?

For named tuples, you are better off using the typed version typing.NamedTuple [1] instead of the classical one suggested in the article. Aside from providing typing, the typed version has a much nicer syntax to define it and lets you add methods (like dataclasses but unlike classical named tuples)

It's been a while since I worked in python, but aren't the original namedtuples populated with __slots__ instead of a __dict__ which makes them a much better choice for very very large datasets? Albeit at the cost of duck typing.

As an aside, my preference for a class container is dataclass(slots=True) for typing. I’d normally used dataclasses as np array containers vs serialized tuple row objects.

@dataclass(slots=True) works too

typing.NamedTuple also sets `__slots__ = ()`, just like collections.namedtuple.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.