On Thu, Dec 21, 2017 at 10:47 PM Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:
>>> > On Dec 21, 2017, at 3:21 PM, Gregory P. Smith <greg at 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
>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171222/f2aab659/attachment.html>