Repository navigation
Better printing for objects #233
Description
Activity
- This all sounds great!
Sounds good to me. Do you have anything available for this already? Or working on a branch?
Not really working on it yet... just wanted to put the idea out there. I've been using
__str__in this way forTransitionandNetworkobjects (Transition.__str__prints the transition's name, the initial state, the final states, and a list of the names of the ensembles, which are set to something based on the interface values during setup). Example:mstis = paths.MSTISNetwork([ (stateA, interfacesA, "A", opA), (stateB, interfacesB, "B", opB), (stateC, interfacesC, "C", opC) ]) print mstis.from_state[stateA]
returns:
RETISTransition: Out A A -> A or All states except A Interface: 0.0<opA<0.04 Interface: 0.0<opA<0.09 Interface: 0.0<opA<0.16I may play with it a bit in the path movers while working on #227, but ensembles will take a decent bit of work to get right, and I don't plan to do that until I finish #227 and #231.
I added something like
.descriptionfor PathMoveChanges. It strips out all single-subchange moves.Just a quick remark to remind us of what @bolhuis suggested in #364: he proposed the idea that a user might want to see the hierarchical structure of volumes/ensembles. This is something to consider doing as one of the ways to print out the information when we get to this part. @jhprinz : do you think that such a hierarchical view might be able to re-use code from your tree mix-in?
I've been making a few things pretty-printable, but I think we should make some decisions about what functions return what kind of string for our objects.
In particular, I'm thinking about things like
PathMovers andEnsembles, where it would be nice to have a clean string representation. If I want to check that my move scheme from a network is correct, seeing<openpathsampling.pathmover.ReplicaExchangeMover at 0x114025650>doesn't help very much.The common functions here would be
__str__and__repr__. As I understand it,__str__should be easily human-readable, and__repr__should be as close to code that reproduces the object as possible, and most importantly, should be unambiguous. I think we may want to create a third function to print something which is not quite code and not quite human-readable. Maybe call that.description()or something like that?Consider
Ensembleas an example. Right now,Ensemble.__str__prints a set-theoretic description of the ensemble. This is unambiguous, but not really human readable (at least, not for complicated ensembles). I think this should be moved to the.description(or whatever we call it).In many cases, we can assign a name to an ensemble (
Interface 1 from State B,Minus Interface State A), and I've been working on having my network code create those names by default. I think this is what the__str__object should print, with a fallback to calculate something like the.description(but usingnamefor subobjects) ifself.nameis not available.Also,
__repr__(which we have rarely implemented) should be made more like its standard behavior, which is unambiguous and often code-like.Basically, my suggestion is this:
__str__: human readable, simple, not necessarily unambiguous -- usuallyself.nameif availabledescription: sort-of human readable, unambiguous__repr__: code-like, unambiguous