During the Steering Committee presentation at PyCon, it was mentioned
that no one has formally proposed TOML be added to the standard library
(emphasis on formal). THe joke went forth that there would be a flood
of proposals to that end.

So, just to kick this off while the thought is still fresh in a bunch of
people's minds: **should we add a TOML parser to the standard library**?

The main reason this matters is to help encourage adoption of the now
PEP-standardized pyproject.toml. A few projects have cited the lack of
a standardized TOML implementation in the standard library as a reason
not to adopt pyproject.toml...and the topic thus became weirdly
political.

I understand that Brett Cannon intends to bring this up at the next
language summit, but, ah, might as well put the community two-cents in
now, hey?

I, for one, feel like this is obvious.

--
Jason C. McDonald (CodeMouse92)
Author | Speaker | Hacker | Time Lord

On 2021-05-15, Jason C. McDonald <codemouse92@outlook.com> wrote:
> During the Steering Committee presentation at PyCon, it was mentioned
> that no one has formally proposed TOML be added to the standard library
> (emphasis on formal). THe joke went forth that there would be a flood
> of proposals to that end.
>
> So, just to kick this off while the thought is still fresh in a bunch of
> people's minds: **should we add a TOML parser to the standard library**?
>
> The main reason this matters is to help encourage adoption of the now
> PEP-standardized pyproject.toml. A few projects have cited the lack of
> a standardized TOML implementation in the standard library as a reason
> not to adopt pyproject.toml...and the topic thus became weirdly
> political.
>
> I understand that Brett Cannon intends to bring this up at the next
> language summit, but, ah, might as well put the community two-cents in
> now, hey?
>
> I, for one, feel like this is obvious.

How about replacing pyproject.toml with pyproject.json, problem solved.

It's fairly hilarious that PEP 518 even provides a JSON schema
specifying the file format, but then doesn't use JSON and instead
selects a file format that doesn't even have a built-in Python parser.

Op 16-05-2021 om 00:39 schreef Jason C. McDonald:
> During the Steering Committee presentation at PyCon, it was mentioned
> that no one has formally proposed TOML be added to the standard library
> (emphasis on formal). THe joke went forth that there would be a flood
> of proposals to that end.
>
> So, just to kick this off while the thought is still fresh in a bunch of
> people's minds: **should we add a TOML parser to the standard library**?
>

See here:
https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068

> I, for one, feel like this is obvious.
>
You are not the only one. The game is already on for some time.

--
Met vriendelijke groet / Kind regards

Menno Hölscher

> On 15 May 2021, at 23:39, Jason C. McDonald <codemouse92@outlook.com> wrote:
>
> During the Steering Committee presentation at PyCon, it was mentioned
> that no one has formally proposed TOML be added to the standard library
> (emphasis on formal). THe joke went forth that there would be a flood
> of proposals to that end.
>
> So, just to kick this off while the thought is still fresh in a bunch of
> people's minds: **should we add a TOML parser to the standard library**?
>
> The main reason this matters is to help encourage adoption of the now
> PEP-standardized pyproject.toml. A few projects have cited the lack of
> a standardized TOML implementation in the standard library as a reason
> not to adopt pyproject.toml...and the topic thus became weirdly
> political.
>
> I understand that Brett Cannon intends to bring this up at the next
> language summit, but, ah, might as well put the community two-cents in
> now, hey?
>
> I, for one, feel like this is obvious.

I think the python ideas list is a better place to have this discussion.

Barry

>
> --
> Jason C. McDonald (CodeMouse92)
> Author | Speaker | Hacker | Time Lord
> --
> https://mail.python.org/mailman/listinfo/python-list
>

On 5/17/2021 4:29 PM, Barry Scott wrote:
>
>
>> On 15 May 2021, at 23:39, Jason C. McDonald <codemouse92@outlook.com> wrote:
>>
>> During the Steering Committee presentation at PyCon, it was mentioned
>> that no one has formally proposed TOML be added to the standard library
>> (emphasis on formal). THe joke went forth that there would be a flood
>> of proposals to that end.
>>
>> So, just to kick this off while the thought is still fresh in a bunch of
>> people's minds: **should we add a TOML parser to the standard library**?
>>
>> The main reason this matters is to help encourage adoption of the now
>> PEP-standardized pyproject.toml. A few projects have cited the lack of
>> a standardized TOML implementation in the standard library as a reason
>> not to adopt pyproject.toml...and the topic thus became weirdly
>> political.
>>
>> I understand that Brett Cannon intends to bring this up at the next
>> language summit, but, ah, might as well put the community two-cents in
>> now, hey?
>>
>> I, for one, feel like this is obvious.
>
> I think the python ideas list is a better place to have this discussion.

I disagree. Rehashing *opinions* is pretty useless. The issues were
already discussed on
https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068

There are multiple packages. There is no consensus on which to pick,
*if any*. Existing modules apparently include writers, which are
necessarily opinionated (as is formatting of C, Python, html, ...). As
I just noted in the discussion, the stdlib does not have an html writer.
So if we want just a parser, maybe we should generate one from the
grammar. Then there are broader 'What should be in the stdlib discussions.

If anyone has *new information* about toml, post it there.

--
Terry Jan Reedy

On 17/05/2021 18.48, Terry Reedy wrote:

> I disagree.  Rehashing *opinions* is pretty useless. The issues were
> already discussed on
> https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068
>
> There are multiple packages.  There is no consensus on which to pick,
> *if any*. Existing modules apparently include writers, which are
> necessarily opinionated (as is formatting of C, Python, html, ...).  As
> I just noted in the discussion, the stdlib does not have an html writer.

If I'm parsing this correctly, python supports something called a
"writer", which does not mean "somebody who writes python".

Since I've never heard of this[1], I searched on:
python writer
but got stuff about how to write python and how to use python to write
to files.

Assuming that there is a python construct called a writer, could
somebody point me to somewhere that I could read up on them?

[1] Well, I've used csv.DictWriter() which might be an instance.
--
Michael F. Stemper
Galatians 3:28

On 2021-05-18, Michael F. Stemper <mstemper@gmail.com> wrote:
> On 17/05/2021 18.48, Terry Reedy wrote:
>> I disagree.  Rehashing *opinions* is pretty useless. The issues were
>> already discussed on
>> https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068
>>
>> There are multiple packages.  There is no consensus on which to pick,
>> *if any*. Existing modules apparently include writers, which are
>> necessarily opinionated (as is formatting of C, Python, html, ...).  As
>> I just noted in the discussion, the stdlib does not have an html writer.
>
> If I'm parsing this correctly, python supports something called a
> "writer", which does not mean "somebody who writes python".

You are not parsing it correctly. Terry means that at least some
existing TOML modules for Python include facilities for outputting
("writing") TOML as well as reading it, and this makes choosing
between those modules more controversial as there are more subjective
opinions involved in the implementation of writing TOML as opposed to
only reading it.

On 18/05/2021 08.23, Jon Ribbens wrote:
> On 2021-05-18, Michael F. Stemper <mstemper@gmail.com> wrote:
>> On 17/05/2021 18.48, Terry Reedy wrote:

>>> There are multiple packages.  There is no consensus on which to pick,
>>> *if any*. Existing modules apparently include writers, which are
>>> necessarily opinionated (as is formatting of C, Python, html, ...).  As
>>> I just noted in the discussion, the stdlib does not have an html writer.
>>
>> If I'm parsing this correctly, python supports something called a
>> "writer", which does not mean "somebody who writes python".
>
> You are not parsing it correctly. Terry means that at least some
> existing TOML modules for Python include facilities for outputting
> ("writing") TOML as well as reading it, and this makes choosing
> between those modules more controversial as there are more subjective
> opinions involved in the implementation of writing TOML as opposed to
> only reading it.

Okay, thanks.

--
Michael F. Stemper
This post contains greater than 95% post-consumer bytes by weight.