Upgrade of default options to provide information for GUI

[sandorzoletnik]

Here is a proposal for several elements of the upgrade proposal:

The default_options in the functions would be changed to a format which describes the options in detail. The concrete proposal is:
default_options = {'opt1': option description, 'opt2': option_description,...}
option_description is dict with following elements:
'Type': Some type. int, float, string, list, ....
'Value type': 'Discrete' : A list of allowed values
'Range': A two-element list with range limits. Can also be list of lists if multiple ranges
'Value': The values or value ranges
'Default': The default value
'Comment' : This could be used as tooltip in a GUI
The merge_options routine would check whether the value of an option is a dictionary. Of not it considers it as the default value as used now. If it is a dictionary it looks for a 'Default' key. If not found the dictionary is considered as the default value. If found the description is interpreted and other (keyword, config file) values are checked.
Each routine would have a default_options keyword argument which would return the default_options dictionary. This could be used by an automatic GUI generator to generate entry fields for the options, therefore it would be the first step towards a GUI. We could also define a default_arguments keyword which would return the same description (plus position or keyword) for function arguments.

Any comments/proposals?

[thelampire]

I like it, it's a really good idea. I like the fact that there could still be an option of using dictionaries as input variables, as I am already using them with the EFIT plotting options.
A variable like this could also contain information on the object/method itself, not just its option variables. I was thinking about this a while ago, but haven't put enough effort into it yet.

[sandorzoletnik]

I don't propose to change the input arguments to a dictionary, the proposal is to have a disctionary which describes the input arguments and their expected values. The only problem is that the allowed values of one argument might depend on the actual value of another argument. This is not included in the proposal.

[thelampire]

I understand think I understand your proposal.
We could also think about creating a new object for such a description. After a while, if a GUI needs to have different options, inputs, etc, a nested dictionary structure can be difficult to understand. I need to think more about this, but it could be an option.