The "range" interestingness test should be renamed

[nth10sd]

While poking at Lithium's import system, I realised it may be best to stop having names that shadow standard function names.

Currently, the range interestingness test shadows the standard python function in Python 2 and Python 3.

@jschwartzentruber what do you think? Would limits, bounds or confines be better? (I prefer either of the first 2)

[nth10sd]

This might actually be a compulsory prerequisite to fixing the import system via PR #28.

[jschwartzentruber]

Is this an issue? I think range is the most obvious name, and it's going to be a clear exception message if someone ever does import range and try to use it like the built-in.

For script usage this is a string arg, so not an issue, and for internal use (none today) this should be an Interestingness class as discussed elsewhere, where the name would not collide.

[nth10sd]

In order for the imports to work correctly in my PR, the __init__.py file in interestingness folder looks like this (might get overwritten as the PR gets updated, reproduced here):

from __future__ import absolute_import

from . import crashes
# from . import diffTest  # diffTest is not used outside of Lithium
from . import envVars
from . import fileIngredients
from . import hangs
from . import outputs
# from . import range  # shadows standard python function
from . import timedRun
from . import ximport

Re: the line involving range, do you think this will be an issue?

[nth10sd]

(The correct way to do the imports is to uncomment out the range line, just like the crashes, outputs ones etc.)

[jschwartzentruber]

The only way this is an issue is if someone did from interestingness import *.

[nth10sd]

The only way this is an issue is if

Should we defend against this usage?

The linters also complain about it shadowing a standard function, we'll have to suppress it too.

[nth10sd]

@jschwartzentruber and I discussed this quite comprehensively, and we'll leave this as-is for now. (Or at least until a much more compelling reason forces the change)

The move to a class-based system should bypass us calling the range.py file directly, mitigating somewhat the problems that the name collision w/a standard python function might cause.