Update the README and the landing page #1095
Conversation
|
Test failure is unrelated. |
jbednar
left a comment
jbednar
left a comment
There was a problem hiding this comment.
Nicely done! Thanks for doing this.
| # => {'mode': 'accurate', 'name': 'Processor00042', 'retries': 3, 'verbose': False} | ||
| ``` | ||
|
|
||
| Runtime attribute validation is a great feature that helps build defendable code bases! Alternative libraries, like [Pydantic](https://docs.pydantic.dev) and others, excel at input validation, and if this is only what you need, you should probably look into them. Where Param shines is when you also need: |
There was a problem hiding this comment.
I'd personally say that Pydantic focuses on sanitization or coercion rather than validation, coercing values rather than rejecting them (see pydantic/pydantic#578 (comment)), but maybe that's too much detail to get into here.
There was a problem hiding this comment.
Yeah, I think they've gone back and forth on how they want to describe themselves between validation and parsing/coercion. In v2, they added a strict mode (configurable per class or per field) that prevents coercion, and decided to stick to "validation" (more info in the middle of this long blog post https://pydantic.dev/articles/pydantic-v2#im-dropping-the-word-parse-and-just-using-validate).
I'd prefer to stick to "validation" here as a general term.
| def __init__(self, **params): | ||
| super().__init__(**params) | ||
| self.param.watch(lambda event: print(event), 'a') # 1. | ||
|
|
There was a problem hiding this comment.
Is it truly necessary to have an __init__ here? I worry that it conveys a level of complexity that param users can generally avoid, even when doing reactive programming.
There was a problem hiding this comment.
Well, I could remove it, instantiate the class, and then attach the watcher with sfe.param.watch(...) but it's not the same, as what I generally want is for all the instances to have the watcher set up. I believe that having to override __init__ is very common when writing Parameterized classes (and is a reason why I want to add post_init).
README.md
Outdated
| sfe.b = 'bar' | ||
| # print_b: self.b='bar' | ||
|
|
||
| @param.depends(sfe.param.c, watch=True) # 3. |
There was a problem hiding this comment.
I would suggest not documenting using depends() outside of a class because of how the decorator syntax encourages early binding to a reactive object, which I think limits how the function can be used. I don't know of any advantage that usage has over bind and would always steer users to bind instead when using functions.
There was a problem hiding this comment.
I'm curious about what others think (and believe it's time to reach a clear consensus) so I asked on Discord, quoting your comment. Not sure how long it'll take for people to answer, and if there will actually be a consensus (I guess yes but who knows). In case it takes too long, I think this could still be merged as is, and the README updated based on feedback later.
There was a problem hiding this comment.
I removed these examples.
Co-authored-by: James A. Bednar <jbednar@continuum.io>
|
Added a section with |
Resolves #934
I've wanted for a long time to extend the README with more examples, and update the landing page a little bit too.