On 01/07/2019 17:23, josé mariano wrote: > Dear All, > > Thank you very much for your valuable input. > Thanks Alan for your kind words. I'm not Spanish, I'm Portuguese, but I know > what you mean. > Thomas, I was able to track down the author but he is not willing to release > the source code. The executable is free but apparently the source is not. > > From your comments I came up with this general configuration for the new > software. Please tell me what you think. > > The new software would use a settings files in one "standard" format. I like > INI. It's note very powerful, but is easy to read and enough for the matter > at hand. I could then use configparser to parse the settings to the main > module. One separate module would convert the original format into the new > one. > > The same for the script files. The new format would be plain python, in one > separated file, that could be imported into the main file. A separated module > would convert the old script format to the new one (python). > > Both modules could be run explicitly or the main software would take as input > the original files and run the conversion modules. > > In this way, old users could use their existing scripts and settings files > and new users that are willing to learn some basic python could use the new > format. > > So, besides the new software, i would need to write one module to convert the > settings from the old format to the new one, maybe using the ideas of Thomas, > and another module to convert the sripts. > > Is this a good approach. You comment are very welcome.
Sounds reasonable to me. Personally I prefer YAML (parsed e.g. with the ruamel.yaml module) to INI because it's more flexible: you get (deeper) nesting and data types (i.e. numbers and strings are different) - but configparser is a fine module to use for config files. Some people like using Python modules as config files. Obviously, as Cameron points out, using Python instead of a custom scripting language has security implications, that go with the increased power that the user has. However, in a laboratory setting, where the users are scientists who have physical access to the machine anyway, I really don't think this is a concern. And the added flexibility may be worth a lot down the line! (I would say that though, as I suggested it) Don't forget that many scientists frequently use Python anyway. - Thomas -- https://mail.python.org/mailman/listinfo/python-list
