On Thu, Aug 22, 2013 at 4:15 AM, Jerry Hill <malaclyp...@gmail.com> wrote: > On Wed, Aug 21, 2013 at 1:55 PM, <random...@fastmail.us> wrote: >> I think, though, that if there's any useful information that can be >> obtained by reading accepted PEPs but not the documentation, or if >> things are explained less clearly than in the PEPs, that's a bug in the >> documentation, and should be remedied by adding to the documentation. > > Personally, the only PEPs I've used as reference material as PEP 8 > (the Python Style Guide), and PEP 249 (the Python Database API > Specification v2.0). If I recall correctly, one of the database > adapters I used basically said that they were PEP 249 compliant, and > didn't have much documentation beyond that. > > It seems to me that adding the PEPs to the compiled documentation > would be a good thing. They are at least as useful as the Language > Reference or the Embedding and Extending Python sections that are > already included.
Ah, yes, there are a few that would be good. But I don't really see that all the internally bits (PEP 393, anyone?) and rejected proposals (PEP 315) need to be in the download. I wouldn't expect the full set of RFCs to be included with the docs for the socket module, so I equally don't expect the PEPs to be included. ChrisA -- http://mail.python.org/mailman/listinfo/python-list