[Python-Dev] PEP 557: Data Classes (original) (raw)

Eric V. Smith eric at trueblade.com
Sun Sep 10 12:36:10 EDT 2017

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.

More information about the Python-Dev mailing list