> 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”, but someone would have to do the work, and I’m not sure who is volunteering (though there’s a risk that it’d be me). 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. Instead, it might be a better idea to focus our writing efforts on the SansIO page in the first instance. If we get to a place where we feel like we have a really good handle on how to explain what to do and what not to do, we could reconsider the PEP at that point. Cory _______________________________________________ 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/
