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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4