-
Notifications
You must be signed in to change notification settings - Fork 224
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
Add Pythonic argument options for colorbar frame parameters #2130
Changes from 7 commits
5f33ad7
02040ac
58df83a
7929982
159165c
f866e59
38907cb
4b0b88c
6969845
d141901
f87190d
2eeb95f
0f0aed4
637123a
fd1e863
33bdc8f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
outs: | ||
- md5: 69740a2512fd502e3d53d16bddc0f97c | ||
size: 4878 | ||
path: test_colorbar_frame_list_parameters.png |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
outs: | ||
- md5: b7fc503b09c1c610a22081edf9cc612f | ||
size: 4840 | ||
path: test_colorbar_frame_parameters.png |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
outs: | ||
- md5: 7a8bbd25a40214160f00a5c5bf83f69d | ||
size: 3764 | ||
path: test_colorbar_frame_string_parameters.png | ||
Comment on lines
+1
to
+4
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you delete this file and see if it fixes the test failure? Maybe it's still comparing the old image? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Still no luck, tried deleting both the .dvc file and the image. |
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.
This is a nice backward compatible way of handling old
frame/B
arguments while introducing new user-friendly parameters. I understand that putting the logic here incolorbar
is a good proof of concept. Just want to ask though, what's your medium term plan for this chunk of if-then logic? Specifically, do you think we should duplicate this for every PyGMT module that doesframe/B
, or put it somewhere central (e.g. as a decorator under https://github.com/GenericMappingTools/pygmt/blob/v0.7.0/pygmt/helpers/decorators.py) or something else?I don't want to resurface the discussion in #1082 on dictionary/functions/classes too much, since nothing would get done if just keep talking while not doing anything. But a colleague of mine recently mentioned that using the function based approach in PyGMT (i.e. passing in parameter-arguments like
xlabel="Some label"
) seemed like a good idea, so I can be swayed with going for this approach rather than the over-engineered class-based approach.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.
I agree that it would make sense to have the logic in something like decorators.py and am open to suggestions. I specifically chose to work with
frame
incolorbar
since there aren't a ton of edge cases to support, and it doesn't need to be consistent with other modules (as opposed to adding this logic forframe
with something likegrdcontour
orplot
). I think it can stay incolorbar
for now, but I don't feel that strongly.I don't think I understand the function based approach method you mention; it looks to me like there would still be a parameter
xlabel
that has an argument passed to it. I'm definitely on board with other approaches; I just want to create proofs of concepts to get the ball rolling on more Pythonic arguments.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.
Agree to keep the logic in colorbar for now. The key part is the unit tests really (which tests what the users will be doing). The implementation, be it as a decorator or some if-then check here can change afterwards.
By function-based approach, I meant exactly what you're doing here - doing
fig.colorbar(..., xlabel="something")
. Contrast this with the class-based approach I mentioned in #1082 (comment) that would be like:Function-based approach would be more user friendly (allows for tab-completion). Class-based approach would be more developer friendly (less coding for us).