On May 11, 2016, at 9:46 AM, Nicholas Chammas <nicholas.chammas@gmail.com> wrote:

On Tue, May 10, 2016 at 11:15 AM Donald Stufft donald@stufft.io wrote:

> On May 10, 2016, at 11:00 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
>
> (as an aside, if there's the question of forking an existing parser
> implementation for better vendorability, forking a YAML parser may be
> more useful to third-party folks than forking a TOML parser :-))

I’m seeing what I can come up with (https://github.com/dstufft/yaml) though
I don’t know that I feel like actually maintaining whatever it is I end up
figuring out there.

Did you intend to fork from https://github.com/yaml/pyyaml? I believe the latest PyYAML is actually hosted on BitBucket:
https://bitbucket.org/xi/pyyaml/

Yea, there was only a very tiny, mostly meaningless delta between Github and bitbucket and I’m lazy.

Also, a better starting point than PyYAML may be this existing fork of the library, ruamel.yaml:
https://bitbucket.org/ruamel/yaml
The fork makes several changes which may be relevant to you.

To be clear, my thing was a proof of concept to see how hard it would be to help inform the decision about what file format to use. The PEP has decided that TOML best represents the tradeoffs we want to make so my lib will likely just die on my GitHub :)