Closed nawtrey closed 2 weeks ago
I've thought about this a bit more, and there may be some downsides to creating a new object for storing all of the info. The networkx.MultiDiGraph()
object offers quite a bit of features that may be worth keeping, so it may be better to keep everything within that object instead of making our own. We could inherit its methods into our own object instead, but there may be some reasons not to do that either. Whatever gets us an easy-to-use interface without losing all of the well-developed NetworkX
methods will take the cake.
Before moving forward it would be worthwhile to review other similar objects and see how others are handling similar situations. The MDAnalysis.Universe
object comes to mind.
Addressed in GH-83. Closing.
KDA is in dire need of a more user-friendly interface. Having functional code sorted into function-specific modules isn't always a bad thing, but at this point it is quite cumbersome to perform basic tasks, even for me. It would be nice if we could define a class to handle all of the function calls and data handling so a user can do something like the following, given a pre-defined rate matrix
K
:Having a central object to store all of the various information associated with a kinetic diagram would substantially simplify the process to go from a simple rate matrix to a complex set of expressions or diagrams. I think this would make the user experience much more delightful, and prevent a lot of user errors since some of the functions are a bit tricky to use.