[Python-Dev] pep-0557 dataclasses top level module vs part of collections? (original) (raw)

Gregory P. Smith greg at krypto.org
Thu Dec 21 18:21:30 EST 2017

It seems a suggested use is "from dataclasses import dataclass"

But people are already familiar with "from collections import namedtuple" which suggests to me that "from collections import dataclass" would be a more natural sounding API addition.

But the dataclasses module has additional APIs beyond @dataclass which clearly do not belong at the top level in collections.

Idea: How about making the current dataclasses.dataclass decorator function instead be a callable class instance (ie: it still functions as property, todays dataclasses.dataclass becomes collections.dataclass.call) with all of the current contents of the dataclasses module as attributes of a collections.dataclass class/instance singleton?

It feels like a more natural API to me:

from collections import dataclass @dataclass class ...

and the following APIs show up on dataclass itself:

dataclass.Field, dataclass.field, dataclass.fields, dataclass.make, dataclass.astuple, dataclass.replace, dataclass.asdict, dataclass.FrozenInstanceError, dataclass.InitVar

instead of being in a separate dataclasses module and being a different style of thing to import than namedtuple.

[ if this was discussed earlier for this pep and rejected and I missed it, my apologies, just drop me a reference to that thread if you've got one ]

This isn't a blocker for me. I like having a dataclass implementation no matter how we arrange it. If we go with what's checked in today, a top level dataclasses module, so be it. I'm not going to bikeshed this to death it just feels odd to have such an API outside of collections but figured it was worth suggesting.

Part of me just doesn't like the plural dataclasses module name. I can get over that.

-gps -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171221/5e0dc7cc/attachment.html>

More information about the Python-Dev mailing list