On Fri, Jul 26, 2019 at 5:15 AM Sardorbek Imomaliev <sardorbek.imomaliev@gmail.com> wrote:
Hello everyone, it has been almost a year after this issue was brought up. I suggest starting discussion on this again. I created an issue in python/peps repo https://github.com/python/peps/issues/1133

> Hi, I am sure this was suggested somewhere before, but I couldn't find any references. I think toml file parser should be part of standard library. I know there is discussions like https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704. But toml is now official format for build system via pyproject.toml. So it is very odd that we have to use external tools to parse it.

It's actually not that odd. Think about all the setuptools usage and that isn't in the stdlib either.
Also many tools like black already started using it as configuration file. I know that pyproject.toml wasn't intended for such usecase, but nonetheless it very well may be a centralised configuration file for many QA and dev tools like flake8, coverage etc.

We relaxed the intent of pyproject.toml for those use-cases, so it's officially considered okay. :)

but was pointed that discussion should start here. In the era of 0.x software https://0ver.org I think it is not feasible to always wait till some standard, library or software becomes 1.x, take flask for example it has been years of usage in production before it got 1.x release. TOML standard pretty well defined, it was already chosen as fileformat for our new build system requirements https://www.python.org/dev/peps/pep-0518/. Standard library evolves and grows. I don't see a problem of having not TOML parser in standard library. Or at least some official package that will be defacto shipped with python itself as battery on installation.

1.0 actually isn't that far off: https://github.com/toml-lang/toml/projects/1, so I would still much rather wait for that rather than rush ahead, especially since we have survived this long without a TOML parser in the stdlib.


As @Anders Hovmöller said in this thread https://mail.python.org/archives/list/python-ideas@python.org/message/OEKD6MFLPGCBSVL3B5VZQOVKXNJ4N53A/
> This thread isn't about regretting past decisions but what makes sense given
current realities though.

I see this could be solved in one of these ways
1) We add TOML in standard library and have versioned parsers like TOMLParser05, TOMLParser06 etc and current version would be set TOMLParser = TOMLParser05, this way there won't be a problem when standard library and next version of python will ship new standard. Deprecation of parser classes could follow our standard deprecation procedure
2) There could be official TOML parser package under new https://github.com/psf group supervision, which will could be installed to platforms during python installation as pip does currently
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VU6LRLQXVOWF6IWJCTFSWETFX36ERT45/
Code of Conduct: http://python.org/psf/codeofconduct/