> On Aug 8, 2016, at 11:56 AM, Cory Benfield <c...@lukasa.co.uk> wrote: > > >> On 8 Aug 2016, at 16:47, Guido van Rossum <gu...@python.org> wrote: >> >> OK, never mind Impostor Syndrome... How can we move this forward in >> the community though actual applications? Should we have the complete >> I/O-free HTTP parser in the stdlib, or is that a bad idea? Do we want >> a PEP? Is there something we could add to PEP 8? > > Addressing those in turn: > > Yes, we could put the I/O free HTTP parser in the stdlib. That’s really > Nathaniel’s call, of course, as it’s his parser, but there’s no reason we > couldn’t. Of course, all the regular caveats apply: we’ll want to give it a > while longer on PyPI to bake, and of course we have to discuss where the > logical end of this. How obscure does a protocol have to be for having a > parser in the stdlib to no longer be sensible? > > Having a parser in the stdlib also raises another question: does the http > module get rewritten in terms of this parser? The obvious answer is “yes”,
This — we have to validate that h11 has the correct design *before* including it to the stdlib. So the answer is “yes”, indeed. > > As to having a PEP or putting something in PEP 8, I feel pretty lukewarm to > those ideas. If the core Python team was able to legislate good coding > practices via PEPs I think the world would be a very different place. What does this mean? A lot of people, in any serious project at least, follow PEP 8 and coding with linters is a wide-spread practice. Yury _______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
