I'd like to get a consensus on naming for IMP modules and classes (well, OK, I'm going to say what I think it should be, and people can agree or disagree).
Currently, on the C++ side, all classes use a Capitalized_Words_With_Underscores naming scheme (e.g. Restraint_Set) and live in the 'imp' namespace. This is translated to the 'imp2' module on the Python side, with the same class names. This has a few problems:
1. The Python 'imp2' name is ugly - Bret presumably had to call it that because Python has a built-in module called 'imp' already. The Python guys (http://www.python.org/dev/peps/pep-0008/) prefer "short, lower-case" names for modules, but I don't think this really makes sense for initialisms anyway - for example, there are already EMAN and CORBA Python libraries out there (the BALL guys also use "BALL"). So I propose "IMP".
2. Python pretty much mandates CamelCase for class names (e.g. RestraintSet). Since the Python class names match the C++ names, we either have to do lots of ugly renaming in the Python interface, or just rename the C++ classes to match. Lots of C++ people use CamelCase anyway (e.g. BALL at http://www.bioinf.uni-sb.de/OK/BALL/Documentation/1.1.1/V1.1.1/hierarchy_htm...). So I propose CamelCase names for IMP C++ classes.
3. There are a bunch of utility Python modules in tests/python_libs: IMP_Modeller_Intf.py IMP_Test.py IMP_Utils.py load_imp_xml_model.py I propose renaming these to IMP.modeller, IMP.test, IMP.utils, IMP.xml.
4. I propose renaming derived classes such as imp::RSR_Exclusion_Volume (exclusion volume restraint, although what the second R in RSR stands for, I don't know ;) as either imp::ExclusionVolumeRestraint or imp::restraint::ExclusionVolume. I prefer the latter because it would more easily translate into the Python IMP.restraint.ExclusionVolume class, and by changing from a class name prefix (RSR) to a namespace we both allow for more readable Python scripts (e.g. "import IMP.restraint as r; r.ExclusionVolume()" or even "from IMP.restraint import *"), and finally because this would greatly simplify moving restraints to their own C++ module.
What do others think?
Ben