hukkin / tomli-w Goto Github PK

As a prettier option and a big improval for tests that compare a toml file, I think a sort_keys like json option is useful.It ensure two toml file with same content will be able to do a text-compare after sorting keys.

Dear Taneli,

thanks a stack for conceiving and maintaining this excellent library. We just wanted to let you know about an issue we just discovered when serializing NoneType values [1]. We are aware that TOML does not know about any kinds of NULL values (toml-lang/toml#921).

Differently than #34, this issue is merely a proposal to handle NoneType values gracefully by just ignoring them on serialization. The toml package does just that [2]. We have exercised the situation with all of toml, tomlkit, and tomli-w on behalf of a unit test at [3] and also reported the same issue to the author of tomlkit at python-poetry/tomlkit#240.

With kind regards,
Andreas.

[1] isarengineering/SecPi#25
[2] isarengineering/SecPi#27
[3] https://gist.github.com/amotl/4d8bc928d781a5d0fbc7f404396f8417

I was wondering if it would be feasible to output comments?

Why? I wrote some code that generates a "reference" config file, with all the keys available to configure an application. I thought that it would be nice to have a comment to each key with some explanation of possible values and what the key does.

What do you think? For example people might have a list and then cast it as a set to remove duplicates.

tomli_w/_writer.py

ARRAY_TYPES = (list, set, tuple)

tests/test_types.py

def test_set():
    obj = {"test-set": {1, 2, 3}}
    assert (
        tomli_w.dumps(obj)
        == """\
test-set = [
    1,
    2,
    3,
]
"""
    )

Problem: Short dict/table values don't get written as inline tables

Version: 1.0.0

code:

import tomli_w
stuff = {'things': {'what':1, "else": 2}}
tomli_w.dumps(stuff)

Current behavior:
output:

[things]
what = 1
else = 2

Expected behavior:
output:

things = { what=1, else=2 }

Extras:
Looking at the code, would we not want to call and check is_suitable_inline_table here? https://github.com/hukkin/tomli-w/blob/master/src/tomli_w/_writer.py#L59-L60

Am I doing something wrong?

Hi again,

while working on the test case [1] to outline #39, we also found that, when using the access pattern to directly serialize to a file,

with open("testdrive.toml", "wb") as config_file:
    tomli_w.dump(data, config_file)

tomli_w.dump needs the file to be opened in binary mode (wb) and croaks otherwise. Both the other libraries toml and tomlkit do not have that requirement and work well when opening the output stream in text mode (w).

Do you see a chance to adjust tomli-w accordingly?

With kind regards,
Andreas.

[1] https://gist.github.com/amotl/4d8bc928d781a5d0fbc7f404396f8417

Toml files can be written without values example:

user="[email protected]"
password=

This empty values could be translated to/from None. So I would expect something like:

import tomli_w

doc = {"table": {"nested": {}, "val3": 3}, "val2": 2, "val1": None}
expected_toml = """\
val2 = 2
val1 =

[table]
val3 = 3

[table.nested]
"""
assert tomli_w.dumps(doc) == expected_toml

to work, but it's not the case.

Hi! Below, I provide (A) the output of the latest Tomli-W and (B) what I propose for "simple" lists (i.e. those containing only literal values: booleans, numbers, strings, time). The data is a subset of my real TOML file, only keys and strings are replaced with dummy values. In general, I agree with the current "conservative" approach, but it looks like the chance of getting readable output for "simple" lists will be higher with the proposed approach. To avoid too long lines, the length limit similar to this one can be introduced.

# (A)
[a]
b = [
    "k1",
    8,
    512,
]

[c]
d = [
    "k2",
    1,
    8,
    16,
    1024,
]
e = [
    "k3",
    0.0,
    0.0,
    0.5,
]

[f]
g = [
    "k4",
    5e-05,
    0.005,
]
h = [
    "k5",
    1e-06,
    0.001,
]

# (B)
[a]
b = ["k1", 8, 512]

[c]
d = ["k2", 1, 8, 16, 1024]
e = ["k3", 0.0, 0.0, 0.5]

[f]
g = ["k4", 5e-05, 0.005]
h = ["k5", 1e-06, 0.001]

Hello, thank you very much for the package!

I was wondering if tomli-w has Array of Tables (AoT) support (or at least if you consider this feature something nice to have in the roadmap).
For example, if we take the following conversion:

>>> import tomli_w
>>> example = {'table': {'nested_table': [{'array_options': [1, 2, 3]}, {'another_array': [1, 2]}, {'c': 3}]}}
>>> print(tomli_w.dumps(example))
[table]
nested_table = [
    { array_options = [
    1,
    2,
    3,
] },
    { another_array = [
    1,
    2,
] },
    { c = 3 },
]

The output looks very weird, and a AoT would make it much easier to read... I had to check the standards to believe it is not following a wrong syntax 😝 (it is explicitly discouraged to have line breaks inside inline tables, though)

In the case AoT is supported, the following would read much nicer:

[[table.nested_table]]
array_options = [
    1,
    2,
    3,
]

[[table.nested_table]]
another_array = [
    1,
    2,
]

[[table.nested_table]]
c = 3

In can see that currently nested tables are automatically handled:

>>> example = {'table': {'nested_table': {'value': 42}}}
>>> print(tomli_w.dumps(example))
[table.nested_table]
value = 42
# instead of "[table]\nnested_table = { value = 42 }"

which conceptually is not very different from AoT, right?