Pre-PEP Proposal: Codetags

[Aahz]

In article <42FAF489.3010306 at v.loewis.de>,
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=  <martin at v.loewis.de> 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 (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.