[Python-Dev] PEP 557: Data Classes

[Eric V. Smith]

On 9/10/2017 10:00 AM, Michel Desmoulin wrote:
> The reaction is overwhelmingly positive everywhere: hacker news, reddit,
> twitter.

Do you have a pointer to the Hacker News discussion? I missed it.

> People have been expecting something like that for a long time.

Me, too!

> 3 questions:
> 
> - is providing validation/conversion hooks completely out of the
> question of still open for debate ? I know it's to keep the
> implementation simple but have a few callbacks run in the __init__ in a
> foo loop is not that much complexity. You don't have to provide
> validators, but having a validators parameters on field() would be a
> huge time saver. Just a list of callables called when the value is first
> set, potentially raising an exception that you don't even need to
> process in any way. It returns the value converted, and voilà. We all do
> that every day manually.

I don't particularly want to add validation specifically. I want to make 
it possible to add validation yourself, or via a library.

What I think I'll do is add a metadata parameter to fields(), defaulting 
to None. Then you could write a post-init hook that does whatever 
single- and multi-field validations you want (or whatever else you want 
to do). Although this plays poorly with "frozen" classes: it's always 
something! I'll think about it.

To make this most useful, I need to get the post-init hook to take an 
optional parameter so you can get data to it. I don't have a good way to 
do this, yet. Suggestions welcomed.

Although if the post-init hook takes a param that you can pass in at 
object creation time, I guess there's really no need for a per-field 
metadata parameter: you could use the field name as a key to look up 
whatever you wanted to know about the field.

> - I read Guido talking about some base class as alternative to the
> generator version, but don't see it in the PEP. Is it still considered ?

I'm going to put some words in explaining why I don't want to use base 
classes (I don't think it buys you anything). Do you have a reason for 
preferring base classes?

> - any chance it becomes a built in later ? When classes have been
> improved in Python 2, the object built-in was added. Imagine if we had
> had to import it every time... Or maybe just plug it to object like
> @object.dataclass.

Because of the choice of using module-level functions so as to not 
introduce conflicts in the object's namespace, it would be difficult to 
make this a builtin.

Although now that I think about it, maybe what are currently 
module-level functions should instead be methods on the "dataclass" 
decorator itself:

@dataclass
class C:
   i: int = dataclass.field(default=1, init=False)
   j: str

c = C('hello')

dataclass.asdict(c)
{'i': 1, 'j': 'hello'}

Then, "dataclass" would be the only name the module exports, making it 
easier to someday be a builtin. I'm not sure it's important enough for 
this to be a builtin, but this would make it easier. Thoughts? I'm 
usually not a fan of having attributes on a function: it's why 
itertools.chain.from_iterable() is hard to find.

Eric.