New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOC: Add a "User messaging" design doc #7310
Conversation
Codecov ReportPatch coverage has no change and project coverage change:
Additional details and impacted files@@ Coverage Diff @@
## master #7310 +/- ##
==========================================
+ Coverage 90.61% 90.76% +0.15%
==========================================
Files 324 325 +1
Lines 43034 43244 +210
Branches 0 5766 +5766
==========================================
+ Hits 38994 39252 +258
+ Misses 4040 3976 -64
- Partials 0 16 +16 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for writing this up, this summarizes a lot of principles and guidelines really well. I left a few comments. Overall, I would agree with almost everything you outlined here, and I'm also curious what @yarikoptic and @mih say.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for writing this up. I think it will need a few iteration to bring us all on the same page. I have left a bunch of comments.
In general, I'd prefer if we try to find the strongest language that we can. I fear that with shoulds and mays, we and up with something that is hard to use as an actionable specification.
------------------ | ||
|
||
In general, **exceptions should be raised when there is no way to ignore or recover from | ||
the offending action**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO This is not an optimal statement, but I cannot come up with a better one, quickly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this statement is concerning only Interface
s implementations, then I would agree. But then there is no clarity on either it concerns those or any part of the code, e.g. a function, which might be just compute_y(x)
and which
- if just a regular classical Python function -- would raise ValueError or TypeError exception
- if somehow is "an interface" -- yield "impossible" record.
how does developer to decide between the two?
Overall -- is this document specifically just about subclasses of Interfaces or only the first section on return records is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall -- is this document specifically just about subclasses of Interfaces or only the first section on return records is?
I think it's both. The main theme is user messaging, and the reality is that most of that happens in response to a call via the Interface
class. But also: we aren't giving general advice i.e. it should not be seen as a comment on what to do with general/classic Python code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some thoughts, haven't finished review though so may be some are premature
Note: the PR is still in draft because of the section |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx for taking that on, @jsheunis!
Co-authored-by: Benjamin Poldrack <bpoldrack@users.noreply.github.com>
Co-authored-by: Benjamin Poldrack <bpoldrack@users.noreply.github.com>
Co-authored-by: Benjamin Poldrack <bpoldrack@users.noreply.github.com>
@datalad/developers thanks for the comments so far. I must still add minor updates after the review of @bpoldrack. And then I would like input on whether we need examples or not? And lastly, a last sanity check on the latest state would probably be a good idea, for those who care strongly about the content here. |
Comments by @yarikoptic in a dev call: examples could point to commit-tracked implementations in existing code. |
fee7a8f
to
fc28212
Compare
Code Climate has analyzed commit fc28212 and detected 0 issues on this pull request. View more on Code Climate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
quickly spotted the NameError: name 'command' is not defined
so left some suggestions ;-)
Co-authored-by: Yaroslav Halchenko <debian@onerussian.com>
@yarikoptic thanks, I committed the suggestions |
Thank you @jsheunis for pushing it through! |
PR released in |
This PR:
TODOs: