You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This can make it easier to represent information as just a set of operations between fig, axs and kwargs. We can move all the plotting functionality outside the classmethods and maybe make it more reusable? This way we avoid
def current_plotting_function():
fig, ax = self.another_function(...)
ax.do_something()
self.another_function_in_this_class(fig, ax) # can mutate the fig, ax object directly and sometimes not accessible at a higher level
return fig, axs
The text was updated successfully, but these errors were encountered:
I'm in favor of this, only curious about the exact scope especially from user perspective. If it's about moving all plotting functionality in a viz module while still keeping the same user-facing methods, then I think it sounds great. It's also in line with what we discussed about "properly" eliminating matplotlib as a core dependence.
Break this up:
viz
(fig, axs)
mechanism.object.plot
functions using theviz
module as an internal function call ontoself
.Based on a conversation I had with Marc and my own personal experience:
Maybe it'd be nicer in terms of extensibility if we had purely functional plotting? Something on the lines of:
This can make it easier to represent information as just a set of operations between fig, axs and kwargs. We can move all the plotting functionality outside the classmethods and maybe make it more reusable? This way we avoid
The text was updated successfully, but these errors were encountered: