(original) (raw)
On Thu, Dec 21, 2017 at 10:47 PM Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
\> On Dec 21, 2017, at 3:21 PM, Gregory P. Smith <greg@krypto.org> wrote:
\>
\> 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.
This might make sense if it were a single self contained function. But dataclasses are their own little ecosystem that warrants its own module namespace:
\>>> import dataclasses
\>>> dataclasses.\_\_all\_\_
\['dataclass', 'field', 'FrozenInstanceError', 'InitVar', 'fields', 'asdict', 'astuple', 'make\_dataclass', 'replace'\]
Also, remember that dataclasses have a dual role as a data holder (which is collection-like) and as a generator of boilerplate code (which is more like functools.total\_ordering).
I support Eric's decision to make this a separate module.
sounds good. lets leave it that way. dataclasses it is.
if we were further along in figuring out how to remove the distinction between a class and a module as a namespace I'd suggest the module name itself be dataclass with a \_\_call\_\_ method so that the module could be the decorator so we could avoid the antipattern of importing a name from a module into your local namespace. but we're not, so we can't. :)
-gps
Raymond