On Thu, 25 Jul 2019 at 15:53, Nam Nguyen <bits...@gmail.com> wrote: >> You need to start by getting agreement on the premise that adding a >> newly-written parser to the stdlib is a good idea. And so far your >> *only* argument seems to be that "it will avoid a class of security >> bugs" which I find extremely unconvincing (and I get the impression >> others do, too). > > Why? What is unconvincing about a parsing library being able... parse (and > therefore, validate) inputs?
Nothing. But why replace existing, working code, with brand new, untried code? And in particular in security sensitive areas? We have parsing code, it was just written by hand rather than by using a library (which likely didn't exist at the time). But it's had literally years of testing in real world situations by now, so any problems from having written it by hand have probably been dealt with by now. Let me turn your question back on you. What is difficult to understand about the idea that replacing existing, working code is a risk, and needs to be justified? >> I think you need to stop getting distracted by details, and focus on >> your stated initial request "Whether we want to have a (possibly >> private) parsing library in the stdlib". You don't seem to me to have >> persuaded anyone of this basic suggestion yet, > > Good observation. How do I convince you that complex input validation tasks > should be left to a parser? You don't have to - I'm completely convinced of that fact. How do *I* convince you that replacing existing, working code needs a better justification than "we should have done it this way originally"? Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VY77KVO5D2RXWQ5JMZR746RTARYP5WDM/ Code of Conduct: http://python.org/psf/codeofconduct/
