improved specifications for keyword arguments of run method#3191
improved specifications for keyword arguments of run method#3191amdnsr wants to merge 2 commits intoMDAnalysis:developfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #3191 +/- ##
========================================
Coverage 92.73% 92.73%
========================================
Files 168 168
Lines 22683 22684 +1
Branches 3213 3213
========================================
+ Hits 21035 21036 +1
Misses 1600 1600
Partials 48 48
Continue to review full report at Codecov.
|
|
I preferred not to delete the argument |
|
Please provide me some feedback on the pull request. |
|
@amdnsr one of the @MDAnalysis/gsoc-mentors will review your PR as soon as they can. Reviews often take a few days as all developers on the project are volunteers, so we often have our own work priorities that come before MDAnalysis. |
lilyminium
left a comment
There was a problem hiding this comment.
Thanks for looking at this, @amdnsr. Please add a test so you can know that your changes work. You should also document kwargs in the docstring and update CHANGELOG (message of what your fix is, and your GitHub username on top). As this is your first contribution to MDAnalysis, please also add yourself to AUTHORS.
| for i, ts in enumerate(ProgressBar( | ||
| self._trajectory[self.start:self.stop:self.step], | ||
| verbose=verbose)): | ||
| **kwargs)): |
There was a problem hiding this comment.
May I ask why you didn't simply verbose=verbose, **kwargs? That way you don't have to modify the kwargs dictionary.
There was a problem hiding this comment.
Hey, I tried that, and yes, I won't have to modify the kwargs dictionary in the run function of base.py file, but the kwargs dictionary in the __init__ function of log.py file is expecting verbose to be a key in its kwargs dictionary, but in the suggested way, verbose will be a named parameter, and not a key in the kwargs dictionary of the __init__ function.
So, I would have to instead do the modifications over there.
This modification seemed cleaner to me, thus, I did it this way, but if the suggested way (verbose=verbose, **kwargs) is preferred, I will do it that way instead.
There was a problem hiding this comment.
Also, please guide me on creating the tests. From what I understand, I need to create a function at the end of the testsuite/MDAnalysisTests/analysis/test_base.py file, that calls the ProgressBar, with some kwargs, which will in turn be passed to tqdm, and consequently, affect the position of each individual ProgressBar.
But, I can't figure out how and what set of methods/functions to call to do it, and how to verify whether my function is behaving as expected.
Thanks
There was a problem hiding this comment.
Have a look at the tqdm documentation for possible parameters you could pass through, and the existing ProgressBar tests in MDAnalysis for suggestions on how you could test for progress bar appearance. We also have a brief guide for writing tests in the user guide.
There was a problem hiding this comment.
Hey, I tried that, and yes, I won't have to modify the
kwargsdictionary in the run function of base.py file, but thekwargsdictionary in the__init__function of log.py file is expecting verbose to be a key in itskwargsdictionary, but in the suggested way, verbose will be a named parameter, and not a key in thekwargsdictionary of the__init__function.
So, I would have to instead do the modifications over there.
I don't think I understand what you mean here. Could you show me your suggested changes? If you just pass in verbose=verbose, **kwargs, the log.ProgressBar class will consider both of them to be in kwargs due to dictionary unpacking
|
@amdnsr the deadline for GSoC applications is rapidly approaching. Are you still interested in completing this? |
package/CHANGELOG
Outdated
| * release numbers follow "Semantic Versioning" http://semver.org | ||
|
|
||
| ------------------------------------------------------------------------------ | ||
| 04/06/21 amdnsr |
There was a problem hiding this comment.
There's already a 2.0.0 entry below, you should only need to add your entry there.
There was a problem hiding this comment.
Apologies, I did not get it. Should I add my changes just above the following line?
09/05/19 IAlibay, richardjgowers
- 0.20.1
There was a problem hiding this comment.
No, there's already an existing 2.0.0 entry just below, this is where it should go.
…kwargs in the docstring.
IAlibay
left a comment
There was a problem hiding this comment.
@amdnsr just a reminder that there's only a few days left before the GSoC deadline. You'll need to address @lilyminium's comments in order for this PR to progress.
| - Leonardo Barneschi | ||
|
|
||
| - Ahmad Nasir | ||
| External code |
There was a problem hiding this comment.
Please make sure that you keep the empty line between the author list and the "External code" heading.
|
@amdnsr are you still looking to work on this? |
|
Closing PR as stale. |
Fixes #3190
Changes made in this Pull Request:
kwargsinrunmethodverbosea part ofkwargsbefore passing it toProgressBarconstructorPR Checklist