Issue 43905: dataclasses.astuple (and .asdict) do deepcopy on all fields

It seems that the 'dataclass.astuple' function does a deepcopy of all fields. This is not documented. Two problems:

1. Dictionary keys that rely on object identity are ruined:
    import dataclasses
    @dataclasses.dataclass
    class Foo:
        key: object
    key = object()
    lut = {key: 5}
    (y,) = dataclasses.astuple(Foo(x))
    # KeyError
    lut[y]

2. dataclasses can only be converted to a tuple if all fields are serializable:

    import dataclasses
    @dataclasses.dataclass
    class Foo:
        f: object
    foo = Foo(open('test.py'))
    dataclasses.astuple(foo)

->

TypeError: cannot pickle '_io.TextIOWrapper' object


In my use case, I just want a list of all fields. I can do the following as a workaround:
  (getattr(foo, field.name) for field in dataclasses.fields(foo))

Tested on Python 3.8.7 and 3.7.9.

Unfortunately this can't be changed, although I suppose it should be documented.

In general I think this API was a mistake, and should not have been added. There are just too many cases where it doesn't do what you want, or where it fails.

I'd like to deprecate it and remove it (along with asdict), but I fear that would be too disruptive.

Your approach seems reasonable to me for your use case.

Why deepcopy is used at all? It is a very specific feature which should not be used by default. If you want to make a deep copy of fields, you can call copy.deepcopy() explicitly.

    copy.deepcopy(dataclasses.astuple(obj))

or

    dataclasses.astuple(copy.deepcopy(obj))

The reason for the deep copying was to support changing a hierarchy of dataclasses into something that could be JSON serialized. But it didn't really work out. It recurses into dataclasses, namedtuples, lists, tuples, and dicts, and deep copies everything else.

As I said, it's a design flaw.

Would it make sense to make dataclasses iterable, like so?

    def __iter__(self):
        return (getattr(self, field.name) for field in fields(self))

With that in place, deprecating astuple would maybe be less disruptive?

No, iteration is explicitly a non-goal of PEP 557. See the section on namedtuple for why: https://www.python.org/dev/peps/pep-0557/#why-not-just-use-namedtuple

I've added a PR here: https://github.com/python/cpython/pull/26154

Eric: I've closed a similar issue about asdict() and now updating the title to keep track of both in this issue. Let me know if you want to keep them separate instead.

I think it's find to address both of these here.

New changeset c1f93f0d378958dfae4f24aad0c0088e3e04e403 by andrei kulakov in branch 'main':
bpo-43905: Expand dataclasses.astuple() and asdict() docs (GH-26154)
https://github.com/python/cpython/commit/c1f93f0d378958dfae4f24aad0c0088e3e04e403

New changeset 376b24e4f69cba53bae9856e9d076af47bb2b6c6 by Miss Islington (bot) in branch '3.9':
bpo-43905: Expand dataclasses.astuple() and asdict() docs (GH-26154)
https://github.com/python/cpython/commit/376b24e4f69cba53bae9856e9d076af47bb2b6c6

New changeset 32f1491a9770b7f2989507ecf8f13ef35dd95b0b by Miss Islington (bot) in branch '3.10':
bpo-43905: Expand dataclasses.astuple() and asdict() docs (GH-26154)
https://github.com/python/cpython/commit/32f1491a9770b7f2989507ecf8f13ef35dd95b0b

Thanks, @andrei.avk!

Thank  you for reviewing Eric!

resolution: fixed
stage: patch review -> resolved

pull_requests: + pull_request24788
stage: patch review

messages: + msg391518
nosy: + eric.smith