On Thu, Jul 25, 2019 at 2:32 AM Paul Moore <p.f.mo...@gmail.com> wrote:
> On Thu, 25 Jul 2019 at 02:16, Nam Nguyen <bits...@gmail.com> wrote: > > Back to my original requests to the list: 1) Whether we want to have a > (possibly private) parsing library in the stdlib > > In the abstract, no. Propose a specific library, and that answer would > change to "maybe". > I have no specific library to propose. I'm looking for a list of features such a library should have. > > > and 2) What features it should have. > > That question only makes sense if you get agreement to the abstract > proposal that "we should add a parsing library. And as I said, I don't > agree to that so I can't answer the second question. > As Chris summarized it correctly, I am advocating for a general solution to individual problems (which have the same nature). We can certainly solve the problems when they are reported, or we can take a proactive approach to make them less likely to occur. I am talking about a class of input validation issues here and I thought parsing would be a very natural solution to that. This is quite similar to a context-sensitive templating library that prevents cross-site-scripting on the output side. So I don't know why (or what it takes) to convince people that it's a good thing(tm). > > Generally, things go into the stdlib when they have been developed > externally and proved their value. The bar for designing a whole > library from scratch, "specifically" targeted at stdlib inclusion, is > very high, and you're nowhere near reaching it IMO. > This is a misunderstanding. I have not proposed any from-scratch, or existing library to be used. And on this note, please allow me to make it clear once more time that I am not asking for a publicly-facing library either. > > > These are good points to set as targets! What does it take for me to get > the list to agree on one such set of criteria? > > 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? > But even if "using a real parser" was useful in that > context, there's *still* no argument for writing one from scratch, > rather than using an existing, proven library. Never a goal. > At the most basic > level, what if there's a bug in your new parsing library? If we're > using it in security-critical code, such a bug would be a > vulnerability just like the ones you're suggesting your parser would > avoid. Are you asking us to believe that your code will be robust > enough to trust over code that's been used in production systems for > years? > > 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? Thanks! Nam
_______________________________________________ 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/FCPU4ZW43G3G6JZHJTD33MT7SYI3DBQY/ Code of Conduct: http://python.org/psf/codeofconduct/
