<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 21, 2017 at 10:47 PM Raymond Hettinger <<a href="mailto:raymond.hettinger@gmail.com">raymond.hettinger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Dec 21, 2017, at 3:21 PM, Gregory P. Smith <<a href="mailto:greg@krypto.org" target="_blank">greg@krypto.org</a>> wrote:<br>
><br>
> It seems a suggested use is "from dataclasses import dataclass"<br>
><br>
> 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.<br>
<br>
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:<br>
<br>
>>> import dataclasses<br>
>>> dataclasses.__all__<br>
['dataclass', 'field', 'FrozenInstanceError', 'InitVar', 'fields', 'asdict', 'astuple', 'make_dataclass', 'replace']<br>
<br>
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).<br>
<br>
I support Eric's decision to make this a separate module.<br></blockquote><div><br></div><div>sounds good.  lets leave it that way.  dataclasses it is.</div><div><br></div><div>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. :)</div><div><br></div><div>-gps <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Raymond<br>
<br>
<br>
</blockquote></div></div>