Current status (tl;dr for users): For a single-frame contact map, you should use ContactFrequency with a single-frame trajectory.
#cmap = ContactMap(traj, frame=0) # old
cmap = ContactFrequency(traj[0]) # new
As of the 0.7.0 (including the development branch), using ContactMap will give an error.
(original post follows)
Currently, Contact Map Explorer has classes ContactMap and ContactFrequency. Really, a ContactMap is nearly indistiguishable from a ContactFrequency with only one frame -- at least, I don't think there's anything ContactMap does that ContactFrequency doesn't -- so it seems logical to remove the extra code.
Here's my proposed process for doing that:
- 0.6.0: Deprecate
ContactMap
- 0.7.0: Remove
ContactMap; leave a function that gives an error saying to use ContactFrequency. Also, FutureDeprecationWarning on Contact Frequency for the name change to ContactMap
- 0.8.0 or 1.0.0: Deprecate
ContactFrequency, with the ContactMap name preferred. Leave a deprecated ContactFrequency until 2.0 (which may be a very long time).
Each release will also include other features, but I'm going to encourage a fast release cycle here (add a new feature-level change? good reason for a new release!) Unfortunately, that also means that even if this is a reasonable timeline in terms of version numbers, it'll be a fast timeline in terms of months. (I hope.)
Thoughts on this? I plan to pin this issue for a while well after the rename is complete, so any confused users can easily find it.
Current status (tl;dr for users): For a single-frame contact map, you should use
ContactFrequencywith a single-frame trajectory.As of the 0.7.0 (including the development branch), using
ContactMapwill give an error.(original post follows)
Currently, Contact Map Explorer has classes
ContactMapandContactFrequency. Really, aContactMapis nearly indistiguishable from aContactFrequencywith only one frame -- at least, I don't think there's anythingContactMapdoes thatContactFrequencydoesn't -- so it seems logical to remove the extra code.Here's my proposed process for doing that:
ContactMapContactMap; leave a function that gives an error saying to useContactFrequency. Also, FutureDeprecationWarning onContact Frequencyfor the name change toContactMapContactFrequency, with theContactMapname preferred. Leave a deprecatedContactFrequencyuntil 2.0 (which may be a very long time).Each release will also include other features, but I'm going to encourage a fast release cycle here (add a new feature-level change? good reason for a new release!) Unfortunately, that also means that even if this is a reasonable timeline in terms of version numbers, it'll be a fast timeline in terms of months. (I hope.)
Thoughts on this? I plan to pin this issue for a while well after the rename is complete, so any confused users can easily find it.