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
Naming consistency #1113
Comments
Taking a look at
Yikes. I agree with just changing these without a deprecation. Error message that would result from these changes would be pretty clear to figure out from a user-perspective. |
While I'm on it, here's
For
For
For
|
Plots:
|
In addition to these updates in the code, I'm wondering if we should have something in the docs to indicate what the required variable names are for user input (or some sort of best practices) to better support community contributions: full words, no typical variable symbol names (i.e. no theta, although we allow u, v, w). |
Maybe put something under "Code Style" in the Contributor's guide? The only other thought that comes to mind is to put together a Developer's Guide, maybe renaming Infrastructure Guide and pulling out some thing from the Contributor's Guide. |
One more to add: in |
While this issue is more about function arguments, I noticed that the function |
@jthielen Since we can do that one with a deprecation cycle in 0.12, we should. |
Leading up to 1.0 it would be nice to standardize naming of function arguments, and eliminate any weird abbreviated names (similar to #1107). Things that stand out:
For
kinematics.py
:lats
: both abbreviated and plural when nothing else is.coriolis_parameter
takeslatitude
.thta
infrontogenesis
. At least should betheta
.potential_vorticity_baroclinic
usespotential_temperature
. I think I prefer the latter.height
vs.heights
. We don't have function arguments oftemperatures
, why do we haveheights
? Also,montgomery_streamfunction
usesheight
I'm sure more will pop out, but we need a good review. Changing these is technically an API break, but:
My inclination is to just change these for 1.0 without worrying about a deprecation.
The text was updated successfully, but these errors were encountered: