renamed 'pbc' kwarg to 'wrap' for Group methods#2857
Conversation
|
Hello @richardjgowers! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
Comment last updated at 2022-03-05 16:25:15 UTC |
| """Raises ValueError when both 'wrap' and 'unwrap' are set to True""" | ||
| @functools.wraps(function) | ||
| def wrapped(group, *args, **kwargs): | ||
| if kwargs.get('compound') == 'group': |
There was a problem hiding this comment.
Here we used to allow pbc and unwrap if compound wasn't group, this slipped through review here: https://github.com/MDAnalysis/mdanalysis/pull/2275/files#r296183096
For sanity's sake, I'm saying that if you want a combination of wrapping/unwrapping you need to do multiple calls
|
I'm also not sure what we should target for the pbc deprecation. It's not overly urgent we just need to nudge people away from using |
Codecov Report
@@ Coverage Diff @@
## develop #2857 +/- ##
===========================================
+ Coverage 94.06% 94.11% +0.05%
===========================================
Files 176 190 +14
Lines 23294 24656 +1362
Branches 3305 3309 +4
===========================================
+ Hits 21911 23206 +1295
- Misses 1337 1404 +67
Partials 46 46
Continue to review full report at Codecov.
|
package/MDAnalysis/core/groups.py
Outdated
| @functools.wraps(function) | ||
| def wrapped(group, *args, **kwargs): | ||
| if kwargs.get('pbc', None) is not None: | ||
| warnings.warn("Use 'wrap' kwarg not 'pbc'", DeprecationWarning) |
There was a problem hiding this comment.
The tone sounds a bit harsh, maybe.
|
If you split the PR into two:
|
|
@orbeckst the deprecations are in this PR, |
|
I thought you wanted to get rid of pbc=True for 2.0. You can if you put the deprecations into 1.0.1. Otherwise the next time you can get rid of them is 3.0. |
There was a problem hiding this comment.
Could you please make this a PR against 1.0 (master) to go into 1.0.1?
Then make a second PR against develop where you remove the deprecated functionality. I'd rather remove stuff for 2.0 than let it sit until 3.0. We have a good opportunity for proper cleanup here, and we're already spending user-goodwill so I'd make it count.
|
What's the status of this? I'm making a finalised list of the 2.0 milestones. I've included it for now. |
|
I think my review comment still stands: if anything is removed in 2.0, it needs to be deprecated in 1.x |
|
My opinion remains that
Alternatively, we go ahead with the PR as it stands and allow wrap and pbc as synonyms for 2.x. Given that @richardjgowers and I seem to be of different opinion how to move forward, it would be useful to have some other devs offer opinions. |
Whilst I agree that deprecating in 1.1 would be cleaner. I think at this point we just need to complete #3242 and cut a release. Probably going with synonyms and then deprecating so that we can remove in 3.0 would be our best option. |
|
@IAlibay this one was not on 2.0.0 milestone. It does not have to be because we'll deprecate for 3.0 but because unwrapping is something that we might want for the workshop (?), I thought I mention it. |
Yeah that's why I originally added it to the 2.0 milestone last month. I don't mind either way, we just need to have enough developer time to get it done. How much work is left to deal with here? |
|
@orbeckst are we good moving this to the 2.1 milestone? |
|
sure, move it |
|
Going through the comments, there doesn't seem to be an enormous amount of work to do, except that all the conflicts need to be resolved. |
|
@richardjgowers do you want to give the final touches on that PR? If you don't have time, I should be able to take care of it next week. |
Rename a missed variable and remove calls that use both wrap and unwrap. This commit does not pass the tests because some of them rely on both wrap and unwrap in the same call. This will be fixed in a subsequent commit.
4bf06ef to
e9b5185
Compare
|
I rebased the changes and fixed the conflicts. The tests are broken, though, because some tests have been introduced that rely on both TODO:
|
topologyobjects.Bond.length still has a pdb argument. This commit reflects this.
|
@jbarnoud yes there are some things which have both unwrap and wrap. I think the idea was to first unwrap to calculate e.g. a CoM, then wrap these results back inside. I think this is extremely confusing as it's not clear which of wrap/unwrap is first see #2857 (comment) |
|
@richardjgowers Indeed. Removing ambiguity is a good thing. My main issue with the broken tests is that it is not clear if they are meant to test the wrap and the unwrap. |
Testing deprecated arguments lead to false positives in pylint. This commit ignores the specific warning on the problematic lines.
There was a problem hiding this comment.
I had a quick look and as far as I can tell there are still a few minor documentation issues left.
EDIT: see my earlier comments.
EDIT 2: Some that say "out of date" are still valid, they just had some other changes nearby. I resolved everything that was clearly done. Please look at anything that's not been resolved and then please resolve it yourself — either because you fixed it or because you consider it out of scope or already done. Thanks.
|
I am doing the doc updates. |
- versionchanged for pbc -> wrap everywhere - fixed format of older versionchanged markup - added missing docs for moment_of_inertia() and replaced kwargs with explicit keyword arguments - removed superfluous kwargs from shape_parameter()
|
I hope the tests pass now. I am approving now because I might not be able to get to it later during the day and in principle at least everything is there. Another pair of 👀 would be good before merging. |
d76d3b7 to
75420b6
Compare
Related to issue #1760 in particular @orbeckst here
Changes made in this Pull Request:
The
pbckwarg for center_of_mass has been confusing people for a while, it's not clear if this wraps (ie forcing atoms to inside the unit cell) or unwrap (ie makes bonds whole, possibly putting atoms outside the unit cell).The
pbcoption will still work for now but raise a deprecation warningPR Checklist