On Fri, Jul 26, 2019 at 5:15 AM Sardorbek Imomaliev < [email protected]> 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. -Brett > > As @Anders Hovmöller said in this thread > https://mail.python.org/archives/list/[email protected]/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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/VU6LRLQXVOWF6IWJCTFSWETFX36ERT45/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/YPUSUOV4VEIIEV5LCKGKLQAUBM3VU3CN/ Code of Conduct: http://python.org/psf/codeofconduct/
