In article <[EMAIL PROTECTED]>, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote: >Micah Elliott wrote: >> >> I also have this living as a wiki <http://tracos.org/codetag/wiki/Pep> >> if people would like to add comments there. I might try to capture there >> feedback from this group anyway. First try at a PEP -- thanks for any >> feedback! > >I think you somewhat misunderstood the purpose of the PEP process. >This is meant primarily for enhancements to Python (the language >and its library), and it is meant to save the PEP author from >implementing unagreeable functionality - if the PEP is accepted, >the PEP author is typically expected to implement the proposed >functionality (in many cases, having a draft implementation is >prerequisite to accepting it). > >Both elements seem to be missing your document: it does not propose >changes to the Python language; instead, it proposes a specific >way of writing comments (ie. something that is not relevant to the >Python interpreter or libraries, only to the Python developer). >Also, there is no indication that you would like to implement >something for the PEP: what tool would you like to change in what >specific way?
However, it's also true that there are plenty of informational PEPs, most notably PEP 8 (Python style guide). OTOH, it is also generally the case that such PEPs codify existing practice rather than attempting to create new practices (PEP 6 being a notable counter-example). -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. -- http://mail.python.org/mailman/listinfo/python-list
