Move prince_config role into prince.__init__.py

[afedynitch]

Since I have some mixed experience from MCEq on the config file. The current location of prince_config.py is out of the prince package. So it will show up as single file in the site-packages, once it is installed with pip. A better way that never misses the intialization is the package level of prince, since all modules will require it to be imported first. This would mean that instead of

import prince_config

...
threshold = prince_config.bla
...

it will be simply

import prince

...
threshold = prince.bla
...

The config needs more meat too, like the file downloading, data locations etc.
I can do some first steps if you agree with making this change.

[joheinze]

I am not sure, if this is the best way. This might clutter the prince namespace, i.e. having alot of prince.xxx symbols defined. Right now config is a single dictionary, so this would be fine to be imported as prince.config. However, the dictionary will be directly parsed into the autodoc (I realised, this is how it currently works for data.spec_data). It therefore will be harder to document the config options.

However I think it might be better to do it the way you have done it in MCEq, i.e. having one config module containing several variables directly. We could simply make this a separate module, i.e. prince/config.py instead of prince_config.py. Maybe it also makes sense to write singleton class for the config.

Then importing options would read

import prince.config as config
if xxx > config.tau_decay_threshold:
    ...

Instead of the current notation

from prince_config import config
if xxx > config['tau_decay_threshold']:
    ...

[afedynitch]

Ok, I can live with prince/config.py. A python module behaves by design like a singleton class, so that would be in line with what you suggest.

The problem I have encountered in MCEq is that if you want multiple instances of prince_run with different config settings within the same namespace, there is a problem. Imagine the (artificial case) of having a prince_run with nuclei up to iron and another one with nuclei up to Silicon. Or objects with different thresholds, like you wanna have an insource computation with threshold != np.inf and then a propagation object with threshold = np.inf. That may work, but it becomes cluttered.

In MCEq I solved that by copying config values to the objects that use them on init, but not for all of them. The same thing will occur for the init.py thing that I suggested, so it's a general problem with "configs".