Skip to content
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

Support changing gmt defaults #288

Closed
seisman opened this issue Feb 7, 2019 · 4 comments · Fixed by #293
Closed

Support changing gmt defaults #288

seisman opened this issue Feb 7, 2019 · 4 comments · Fixed by #293
Labels
feature request New feature wanted help wanted Helping hands are appreciated

Comments

@seisman
Copy link
Member

seisman commented Feb 7, 2019

Description of the desired feature

Changing gmt defaults in GMT CLI:

  1. gmt set PAR1=value1 PAR2=value2
  2. gmt plot ... --PAR1=value1 --PAR2=value2

In pygmt, these two should be:

  1. gmt.set(PAR1=value1, PAR2=value2)
  2. gmt.plot(projection="xxx", region="xxx", PAR1=value1, PAR2=value2)

Another way is using dict, e.g. gmt.conf['PAR1']=value1, which seems more pythonic. But we need call gmt set for each assignment. I'm not sure if it's technically possible.

@leouieda
Copy link
Member

leouieda commented Feb 9, 2019

Using the dictionary syntax is doable through __getitem__ but it's probably not worth the added complexity.

I like the set function but not really the upper case arguments to other functions. A better way to have temporary settings would be through a context manger:

with pygmt.set(bla=something):
    pygmt.surface(...)

That would make the documentation of other methods easier because they don't take GMT level configuration parameters. These are all handled by set and can be set globally or temporally.

@liamtoney
Copy link
Member

It seems to me like the most common use case of gmt set is for global changes at the beginning of a script. Wouldn't using a context manager cause the whole script to be indented?

In spite of the apparent added complexity (I'm sorry to comment on something I know so little about here) I feel that a dictionary of values would certainly be most suitable. As @seisman has written it above, this would be essentially analogous to what matplotlib does with matplotlib.rcParams, e.g.

import matplotlib as mpl
mpl.rcParams['lines.linewidth'] = 2
mpl.rcParams['lines.color'] = 'r'

If we were using this dictionary framework I think it would be less weird to use upper case arguments, since they're constants anyhow. This would make it simpler since we wouldn't have to come up with new, lower-case names for all of the default params, and folks could cross over from classic GMT more easily.

@leouieda
Copy link
Member

Wouldn't using a context manager cause the whole script to be indented?

Yep, that would be terrible. The way the new matplotlib styling works is that you can set a style globally or use a context manager to temporarily change the style. We can tell whether the context manager is called inside a with block. So you could:

pygmt.set(PARAMETER=value)  # Global

# Locally set a value that will revert back to the default
with pygmt.set(PROJ_ELLIPSOID=value):
    ...

pygmt.whatever(...)

What do you think?

If we were using this dictionary framework I think it would be less weird to use upper case arguments

That's a good point. But the set function would be using **kwargs anyway, which is basically a dict.

This would make it simpler since we wouldn't have to come up with new, lower-case names for all of the default params

That was never my intension (sorry for not making it clear). We should keep the same parameter names with upper case letters.

folks could cross over from classic GMT more easily

If that's the case, then calling pygmt.set(...) at the beginning of the script is probably closer to what people do in bash scripts, right?

@liamtoney
Copy link
Member

Okay, thanks for the clarification. I think the code block in your comment above represents an ideal implementation since users have both temp and global options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature wanted help wanted Helping hands are appreciated
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants