PEP 20 states:

> There should be one-- and preferably only one --obvious way to do it.

As of right now, two very similar constructions for making a lightweight dataclass exist in Python.

collections.namedtuple is one of them. dataclasses.dataclass is the other*.

The behaviour they provide is very similar. And with the functions .astuple() and the `frozen` constructor argument of the dataclass, one could consider it to be almost a direct superset of the namedtuple.


Having two different classes with very similar behaviour is not considered a good practice. I propose merging the two classes' features into one and to deprecate the other, to prevent unnecessary ambiguity.


* To get deeper into semantics, we might consider types.SimpleNamespace to be the third. This is out of this issue's scope - the reader is welcome to follow up in another one.

They are very different. I don’t see how they could be combined. PEP 557 goes in to some of the differences.

Most of the differences are direct upgrades added in the dataclass module. Deprecating dataclass in favour of nametuple would be counterproductive, I agree - what about vice versa?

namedtuples have features like true immutability, being smaller, and being faster.

Touche. Another advantage a namedtuple has is that it can expand out of the box - i.e., can write something like

> for x, y, z in namedtuple_list:

without any list comprehensions.

Can we bring those advantages into the dataclass while also preserving the interface? Maybe a special version of the implementation behind the scenes, something similar to what C++ does with bool vectors.

Hi Pavel.

Thank you for your submission, but your request is based on a serious misunderstanding of the koan from PEP 20.

You might consider that Python has, for example, both for loops and while loops; it has lists and tuples; it has ints and floats and Decimals.

Even if they were "the same", we would not remove one or the other just to satisfy PEP 20. Even if we did decide to do so, but the process could only *start* in 3.11 or later, 3.6 through 3.10 are all in feature-freeze and no changes except bug-fixes are permitted.

Before we could make such a major change, you would need to discuss this on the Python-Ideas mailing list to gather feedback and support for the idea. You would need to get at least one core developer willing to act as champion for it, and write a PEP. The bug tracker is not the place for this.

I agree with Steven, but since I have this typed up I'll post it here.

Yes, iterability is another namedtuple feature. Although that would actually be easy to add to dataclasses, so I didn't mention it.

I don't really see the point of combining them, except for some conceptual purity argument.

You can already write a wrapper decorator which, given the various parameters to @dataclass, decides if it will produce a dataclass or a namedtuple. For example, there couldn't be any fields with init=False, or kwonly=True, the class would have to have frozen=True, etc.

Thank you all for your input! Migrating the discussion to https://mail.python.org/archives/list/python-ideas@python.org/thread/UQRCDWMFNC5NRLLQCTYPOEGWJOIV7BGJ/ for now, if anyone wants to continue.