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

Suggestions for code improvements #26

Open
ChrisBarker-NOAA opened this issue Jul 26, 2023 · 0 comments
Open

Suggestions for code improvements #26

ChrisBarker-NOAA opened this issue Jul 26, 2023 · 0 comments

Comments

@ChrisBarker-NOAA
Copy link
Collaborator

While working with TAMOC, I have had a number of ideas about code strucutre, etc -- Im lumping them all here so I won't forget. If you want to do any of these, we could start a new issue to discuss (or just do it :-).

numpy warnings

newer numpy raises a lot of warnings on FP operations by default -- it can be pretty annoying, particularly in a Jupyter Notebook. I suppressed a few in the PR: #24, but a more holistic approach would be beter. Options:

  • turn the warnings off in init.py (maybe optionally)
  • use the context manager to turn them off each time they occur, only for those places where it's know to expect them.
  • suggest that users turn them off at the top of their script / notebook -- I haven't tried that yet, but it should work.

MPL structure

use MPL's OO API

It could be helpful to refactor a lot of the platting code to use MPL's "OO api" -- using the axes object, rather than pyplot's state machine / gca, etc (https://matplotlib.org/matplotblog/posts/pyplot-vs-object-oriented-interface/).

This would make it much easier to write DRY (Don't repeat yourself) code -- by passing axesobjects around to code that has to do the same thing to multiple plots, etc.

DRY out the code

There is a lot of repeated MPL code -- if you have multipel figures / axes that share the same style, etc, you can write a function to set al that up, and call it with different axes objects from various places. (this will be esier with the OO interface above)

return Figure objects to platting calls

If a call to plot something returns a Figure object, then client code can use that to resize teh figure, save it out, etc. That would make it easier ot have a nice interactive Notebook that also genetaed figures for use elsewhere.

Use gsw

The gsw package provided state of teh art equation of staet for seawater:
https://pypi.org/project/gsw/
There's probably no need for that level of precision in TAMOC, but it's nice to have code that someone else has maintained an tested. It's installable via PyPI and conda-forge

use NUCOS

NOAA's uit converter is pretty handy:

https://pypi.org/project/pynucos/
https://github.com/NOAA-ORR-ERD/PyNUCOS

also on conda-forge (conda install pynucos)

Balance between another dependency and something with a lot of units that tested an maintained by others (and has weird-ass units like API Gravity)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant