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". > 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. 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. > 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). 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. 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, so asking what the library that no-one has agreed to should look like is unlikely to produce useful feedback. You could of course *change* your main proposal, to something like "should we add parsing library X from PyPI to the stdlib", or "should we rewrite the existing URL parsing code in the stdlib from scratch to make it less likely to have security bugs". I doubt either of those would get much support either, but I could be proved wrong. The key here is to focus on a clear proposal, and not get distracted by implementation details until the principle gets enough support. 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/MUP5TWNWTDSMV42JSYSV6JQ3J4ZLXCV2/ Code of Conduct: http://python.org/psf/codeofconduct/
