Refactor

[kenodegard]

@sdispater I have been working on a refactored version of tomlkit. This new version addresses many of the outstanding issues of the current implementation as well as making the TOML objects more natural. I found that in some cases having TOML objects are simply problematic so I needed a way to quickly convert TOML objects into Python objects (pyobj API).

I fully understand if you don't want these changes, they are broad. One of the underlying goals of this refactor was to make the parsing more modular to where the same parser could be used to parse several different versions of TOML (a very possible future once TOML specifies a versioning pragma/scheme). One of the choices made in this refactor was to no longer perfectly preserve whitespaces. I found too many whitespace instances to be ridiculous to preserve (e.g. this key a . b ."foo" .c). Instead, I make sure to preserve the insert order of comments and key-values but let tomlkit decide how to lay out the TOML object when flattening into a TOML document (str). Some whitespace preservation can be reimplemented without much difficulty (e.g. newlines). We preserve comments and newlines. Adding block indents (as in the entire table gets indented by X spaces) can be added relatively easily. I do not see value in perfectly preserving inconsistent whitespacing and if any whitespace is perserved I would rather see some amount of whitespace standardization (much like black does for Python).

Issues Addressed:

#17
#18
#19
#25
#37

Porcelain API:

• toml: converts Python object into TOML object
• pyobj: converts TOML object into Python object
• loads/parse: converts TOML document (str) into TOML object
• dumps: converts TOML object (convert into base type first) into TOML document (str)
• flatten: converts TOML object (use as is) into TOML document (str)
• load: reads TOML document (str) from filehandle, uses loads
• dump: uses dumps, writes TOML document (str) to filehandle

Other Changes:

The refactor also introduces the ability for tables and inline tables to be interchangeable, rendering of one versus the other is based on a table's complexity which can either be set to true or is derived based on TOML rules (e.g. if a table contains comments it is complex). This same logic is used to toggle between AoT and "inline" AoT.

Influences:

• Large chunks of the code are just the original tomlkit moved around.
• Tables and Arrays were strongly influenced by collections.OrderedDict.

[kenodegard]

Other directions were chosen and this is no longer of interest.