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

[Gregory P. Smith]

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>