Do I need a parser?

Thomas Jollans tjol at tjol.eu
Tue Jul 2 14:47:01 EDT 2019


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



More information about the Python-list mailing list