Pythonise user & process configuration

[robtaylor]

There are a lot of places where configuration is loaded by looking for .py files in various places, using various strategies. This is very unpythonic, and problematic in multiple ways, especially for folk using coriolis as a library.

These need a good overview and ideally a bit of a plan writing up before implementation.

Relevent issue: #63
also places where exec is used:

bootstrap/builder/Configuration.py:            exec( open(self._confFile).read(), globals() )
bora/python/initHook.py:            exec( open(userInit).read() )
crlcore/python/helpers/__init__.py:            exec(open( technoFile ).read())  # moduleGlobals
katana/python/initHook.py:            exec( open(userInit).read() )

Also any code referencing 'CORIOLIS_TOP'/'coriolis_top'

crlcore/src/ccore/Utilities.cpp
crlcore/src/pyCRL/PyCRL.cpp
cumulus/src/designflow/task.py
cumulus/src/designflow/technos.py
flute/src/3.1/PyFlute.cpp
katana/src/KatanaEngine.cpp
unicorn/src/coriolis.py

[jpc-lip6]

This is an aftermath of the migration of Coriolis from C++ with Python scripts to Python modules with C++ code.
As the move in itself was not completely understood/assumed at the time we got this "intermediate" situation.

So, yes, a clear policy should be defined. Nevertheless, I am afraid some unpythonic parts may have to stay due to the very nature of the software.

[robtaylor]

This is an aftermath of the migration of Coriolis from C++ with Python scripts to Python modules with C++ code. As the move in itself was not completely understood/assumed at the time we got this "intermediate" situation.

So, yes, a clear policy should be defined. Nevertheless, I am afraid some unpythonic parts may have to stay due to the very nature of the software.

Which bits are you thinking?