Hi everyone,
Just a quick plug for toml_tools. It combines Taneli Hukkinen’s tomli (which the Python 3.11 core library tomllib was based on) and tomli-w. My contribution was to backport it to Python 2, crossport it to IronPython, and keep all the tests running and passing.
If you find any bugs, please do raise an issue - the tests are extensive, but were all original written for CPython 3.7 - 3.12, so it’s very possible I’ve overlooked areas that should be tested specific to Python 2 or IronPython.
To use it in a plug in, I include a static copy. That’s literally copy and pasted the toml_tools folder from an installation from PyPi in a venv, into a a sub folder of my plug-in’s main combined Python source code / package. I’m pretty sure in a pure python project that’s the same as copying the toml_tools folder in the source repo, but the distinction is important for other things.
My motivation for this was self interest. In order to simplify use of an external application in Grasshopper, I wanted to give plug-in users a way of reducing the spaghetti in their Grasshopper definitions, and to create components that expose as few input Params as possible. I decided to enable users to specify settings that don’t need to change between sheets, or even between users, in an external configuration file.
Python source code is plausible for configuration, but is the very model of an arbitrary code-execution vulnerability. I would prefer not to ask Grasshopper users to edit JSON. YAML is just asking for trouble. And take it from me, working with configparser to support INI files, is taxing to say the least. So last year I was delighted to discover the .TOML format. I like to think I’m seldom draconian, but ever since then, I’ve repeatedly and insistently pushed .toml files on to my small user base!
However I could never find a good pure Python, Python 2 TOML reader and writer. The eponymous toml project seemingly worked for about a year. But then a few weeks ago I realised it wasn’t writing unicode properly. It also had a silly bug. After a long day I fixed that bug. However I then discovered another, and another… And a pattern of neglect, numerous frustrated users, and several projects that had abandoned toml altogether. It dawned on me that there were very good reasons CPython never used toml to read TOML. So at the end of last week I made the decision to abandon toml altogether, and rebuild toml_tools from tomli and tomli-w.
This was pleasantly productive. The code isn’t perfect, but it is quite optimised, and thoroughly tested not only for tomllib in cPython 3.11, but for versions down to 3.7 in tomli. I’ve found it great to work with.
Importantly, I back ported and cross ported tomli and tomli-w’s tests too (from pytest to unittest). They all pass in Python 2 and IronPython (otherwise I wouldn’t be bothering you).
Obviously I have a huge conflict of interest, but if you need a Python toml reader or writer for your own project in Rhino or Grasshopper, I think toml_tools will serve you very well. If you know of a better one, do let me know (I only spent -all- weekend on this. I’ll get over the disappointment of overlooking it eventually 
).
My intention now is to strongly prioritise stability over new features. But the TOML spec itself is still being developed, so never say never.