Moving away from shadowing of built-ins

[matt]

Presently, our namespace intersects with, and overrides, python's. This can cause built in features to be inaccessible. For example, if I import tsse.min, I cannot use the built-in min method. The short-term solution is to "import tsse.min as tmin", but I think it would be a good idea to fix these conflicts.

Problem names include:
- min
- str
- data.point.Type
- use of "type" as a variable in io methods (not a big deal, but it sets the syntax highlighter off)

[ryeterrell]

I think the hard one here is going to be min. This will largely depend on how we implement minimization in the future. I'm currently experimenting with point and dimer to see how this might be done [relatively] cleanly.

As far as the str goes, I think I can clear that up right now by renaming it. I'll give it a go. How do str_old and str_new sound?

I agree, the use of lowercase "type" as a variable should be avoided. Here's some thesaurus entries to help us out: archetype, description, embodiment, epitome, exemplar, exemplarity, exemplification, exemplum, ilk, kidney, model, nature, personification, quintessence, representation, species, stripe, type, typicality, typification [source: thesaurus.com].

(kidney? Really?)

The capital "Type" bothers me less inasmuch as it conflicts with "type", but neither is it very descriptive. As I recall, this needs to be more general-purpose, so "element" or "atomic_number" wont be appropriate. Perhaps this will be a good place for "kidney"?

Just kidding.

[matt]

I'm so tempted to use kidney, but I think I'll fix up the io files with kind replacing type.

As for Type and AtomType, I'm not sure. Changing those will require changing a lot of code, and I think we should think the point object over thoroughly before then.

str_old and str_new sound good for now, but at some point, we should pick the better one and call it string.

[ryeterrell]

str_old and _new are now in the repository. I'll need to examine the examples and fix them.

I understand your sentiment about getting rid of the less efficient string (it would be the "new" string, I believe), but I think at least one of the goals of the tsse package is to provide for some benchmarking of various methods, so we would be keeping it. Also, we've used these codes in some of our papers, and so we would want to keep them around for the purpose of reproducing our results easily.