Replies: 2 comments 6 replies
-
|
Although TOML wasn't designed to be a general-purpose data language, there are lots of tools that allow arbitrary data in their configurations. In the case of In TOML's early days, we rejected nulls in configuration, because we thought that new projects adopting TOML could design their configurations from day one to avoid nulls. But as existing projects transition to TOML, it is getting more difficult to keep this condition, precisely because of the need for naïve data expression. I hate suggesting that we add |
Beta Was this translation helpful? Give feedback.
-
imo features should only be removed from TOML 1.1 at this point and anything else should be slated for a 1.2+. |
Beta Was this translation helpful? Give feedback.
-
@epage Care to clarify? What ought to be removed? Can you file or refer to specific issues, or submit PRs? |
Beta Was this translation helpful? Give feedback.
-
|
That wasn't to say features must be removed for 1.1 but what the mindset should be for 1.1: that of pairing down and focusing , rather than letting any lingering (or new) design discussions get in the way of the "core parts" of 1.1 from becoming available. I previously expressed a similar sentiment in #996. If I were to order and prioritize things
|
Beta Was this translation helpful? Give feedback.
-
|
I think this particular use case for NULL is absolutely unconvincing. Modeling a structured type with 12 fields as a 12-tuple is the worst possible way to go about it. How should people ever remember which value goes in the 9th field and which one in the 11th? Of course they won't. TOML already offers a much better and more intuitive solution for this task: Use a table with keys, omitting the key in cases where it doesn't have a value (corresponding to NULL in SQL). So, in order not to encourage bad design, I would see this particular use case an as argument against rather than in favor of NULL. In any case, if we decide to add |
Beta Was this translation helpful? Give feedback.
-
@ChristianSi You ignored an important condition on this use case. This is an existing project. This isn't a change that we can easily assume that the project team will make. We can't guilt them into using the structured table approach, because they could just as easily fall back to their other configuration methods that permit explicit nulls in lists. And as sloppy as arbitrary data inserts are in theory, they could shoot back with: "we have lots of prewritten code here, we know our own tables, we know our columns, we know what we're doing." I agree that we shouldn't pay the issue of nulls any more mind until after TOML v1.1.0 is released. How we'll reach the release, or even a hypothetical v1.0.1, is another issue best discussed elsewhere. |
Beta Was this translation helpful? Give feedback.
-
|
As a user I don't want to deal with the overhead of checking docs for a given tool's special "NULL" case for each key, and hope that the authors have good taste and consistency. And as a user I don't want to delve into source or documentation to figure out what the "default" is for a given key. That's an implementation detail that I shouldn't have to deal with as a user. As an author I want the ability to have cascading config files and I don't want to reserve a special "NULL" value for each key. I want to be able to use the entire range of the type (ie. an unsigned, unbounded number like JS' BigInt). This came up for me recently as a user with the DVCS Jujutsu, which uses TOML for its config. It has a user-level I had a config key ( How would the JJ authors define a "NULL" string here? An invalid filename as a "default" value? Maybe the JJ maintainers have a cleaner implementation in mind to support this use case, but having a first-class NULL value in TOML seems useful here. |
Beta Was this translation helpful? Give feedback.
-
|
For filenames specifically, '' would be a decent sentinel, since there's no such thing a as file with an empty name. In the long run, maybe we should add |
Beta Was this translation helpful? Give feedback.
-
Just bumped into this limitation in real life, specifically with a list containing nulls
pyproject.toml:"" or {} don't work, they are interpreted as a string/dictionary, not None. This expects exactly 12 values to insert one record into a ?sql? table where all columns except the first one are nullable.
I know the perfect fix would be to improve support of
pyproject.tomlin cx_Freeze. (As opposed to oldersetup.py, which obviously can create tuples with Nones easily). Ideally they should probably represent records in msi tables as a dictionaries and not tuples in the first place. But I can see why they went with the easiest implementation for the niche use-case of creating MSI installers, especially as setup.py was the only way to configure projects, so toml limitations were not even on the horison.But having absolutely no way to represent None/null is still very annoying.
Beta Was this translation helpful? Give feedback.
All reactions