3 ms·

There was a long debate about this, and the conclusion was: There is one way to read toml, but a lot of ways to write it (do you preserve formatting, what do y

There was a long debate about this, and the conclusion was: There is one way to read toml, but a lot of ways to write it (do you preserve formatting, what do you do with comments, do you allow partial updates...). Therefor reading is easy to get right, but writing less so, and once it's in the stdlib, we can't make quick changes to the API. Since reading is already very useful, and tomli author's is ready to provide that for free, let's include it now and see writing later.

coldtea 4y ago
>There is one way to read toml, but a lot of ways to write it (do you preserve formatting, what do you do with comments, do you allow partial updates.. Then don't use TOML for internal stuff? Or just settle on a way your lib writes it, and if every parser out there can read it anyway, and get the same deserialized structure, it doesn't matter which way you write it exactly...
- BiteCode_dev 4y ago
  I'm just giving you a summary of the rational. As for it was a good idea, this has already been debated and acted upon, there is no need to repeat exactly the same arguments. You will find the detailed rational in the PEP, and link to the various discussions.
  - coldtea 4y ago
    >As for it was a good idea, this has already been debated and acted upon, there is no need to repeat exactly the same arguments. Well, the same debates happened over many other decisions debated, acted upon, and later regretted and reverted. At some point the GIL seemed like a good decision too!
    - macintux 4y ago
      Obviously the complexity level is different, but to me you sound like someone complaining about Linux adding support for a new filesystem, but read-only at first. Why all the hostility?
      - coldtea 4y ago
        It's a complain about a release decision. Where's the hostillity? No need to project psychology on it...
    - iainmerrick 4y ago
      That's an argument for not adding a TOML writer right now. The correct design isn't obvious so there'd be a risk of a bad design getting locked in.
    - kortex 4y ago
      The GIL is a good decision and has been a sound engineering tradeoff for decades. It's only been the past few years that running the interpreter without a GIL has been even remotely feasible (cf the gilectomy project). The GIL is a relatively straightforward way to hold back a tremendous amount of complexity. Similarly, TOML writing is a ton of completely. The org isn't opposed to adding toml writing to the stdlib fundamentally, they just aren't rushing and want to hammer out all of the grossness first.
- sgtnoodle 4y ago
  I have plenty of cases with yaml where I care about the formatting of the serialized output. I have to use obscure hooks into pyyaml's inner workings to tweak things just right. In some cases, I end up having to do some of the serialization myself. While technically it doesn't matter because it's all equivalent once in memory, there are externalized costs once you're integrated into a large system. The whole point of using something like yaml or toml is to be human friendly.

coldtea 4y ago

>There is one way to read toml, but a lot of ways to write it (do you preserve formatting, what do you do with comments, do you allow partial updates.. Then don't use TOML for internal stuff? Or just settle on a way your lib writes it, and if every parser out there can read it anyway, and get the same deserialized structure, it doesn't matter which way you write it exactly...

BiteCode_dev 4y ago
I'm just giving you a summary of the rational. As for it was a good idea, this has already been debated and acted upon, there is no need to repeat exactly the same arguments. You will find the detailed rational in the PEP, and link to the various discussions.
- coldtea 4y ago
  >As for it was a good idea, this has already been debated and acted upon, there is no need to repeat exactly the same arguments. Well, the same debates happened over many other decisions debated, acted upon, and later regretted and reverted. At some point the GIL seemed like a good decision too!
  - macintux 4y ago
    Obviously the complexity level is different, but to me you sound like someone complaining about Linux adding support for a new filesystem, but read-only at first. Why all the hostility?
    - coldtea 4y ago
      It's a complain about a release decision. Where's the hostillity? No need to project psychology on it...
  - iainmerrick 4y ago
    That's an argument for not adding a TOML writer right now. The correct design isn't obvious so there'd be a risk of a bad design getting locked in.
  - kortex 4y ago
    The GIL is a good decision and has been a sound engineering tradeoff for decades. It's only been the past few years that running the interpreter without a GIL has been even remotely feasible (cf the gilectomy project). The GIL is a relatively straightforward way to hold back a tremendous amount of complexity. Similarly, TOML writing is a ton of completely. The org isn't opposed to adding toml writing to the stdlib fundamentally, they just aren't rushing and want to hammer out all of the grossness first.
sgtnoodle 4y ago
I have plenty of cases with yaml where I care about the formatting of the serialized output. I have to use obscure hooks into pyyaml's inner workings to tweak things just right. In some cases, I end up having to do some of the serialization myself. While technically it doesn't matter because it's all equivalent once in memory, there are externalized costs once you're integrated into a large system. The whole point of using something like yaml or toml is to be human friendly.