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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
