Please add a co-maintainer

[Spectre5]

@uiri, will you please consider adding @pradyunsg as a co-maintainer as he's offered multiple times in various issues. He's involved with the TOML language spec itself, the greater Python ecosystem, and appears to have more capacity than you currently do to work issues and pull requests. TOML V1.0 was released and it would be great to implement those updates into this project, e.g. mixed-type arrays.

[ofek]

@uiri Any update on this?

[eksortso]

Don't expect any updates until around Halloween. That seems to be the trend that @uiri follows.

This is unmaintainable. This package needs forked. And PyPI needs to track the new fork, since this one's just squatting on the toml name.

[johnthagen]

black, mypy (python/mypy#10824), and coverage have switched to tomli.

Some lengthy discussion about alternatives here:

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

[Spectre5]

I've also since switched to tomli.

[pradyunsg]

I've gone ahead and reached out to @uiri over a separate channel (email). Let's see if I get a response. If I don't, I'm planning on starting a PEP 541 request for maintainership transfer.

[ofek]

@pradyunsg Is that necessary since tomli is becoming more broadly adopted?

[pradyunsg]

Well, it would be good to have tomli's implementation ported over to this name TBH. Having the toml package on PyPI be the canonical and primary implementation that folks would want to use is a much better experience for TOML consumers -- something that I'm interested in. :)

[johnthagen]

Well, it would be good to have tomli's implementation ported over to this name TBH

It would also be nice if TOML support is ever upstreamed into the Python stdlib, to use the canonical toml name as well (and this project could be the canonical backport). @brettcannon has talked about this in the past. Being in the stdlib is also a pre-req for the flake8 developer to adopt pyproject.toml, etc.