[Python-Dev] PEP 350: Codetags

Terry Hancock hancock at anansispaceworks.com
Tue Sep 27 09:09:06 CEST 2005

On Monday 26 September 2005 05:35 pm, Micah Elliott wrote:
> Please read/comment/vote.  This circulated as a pre-PEP proposal
> submitted to c.l.py on August 10, but has changed quite a bit since
> then.  I'm reposting this since it is now "Open (under consideration)"
> at <http://www.python.org/peps/pep-0350.html>.

Overall, it looks good, but my objection would be:

> :Objection: I aesthetically dislike for the comment to be terminated
>     with <> in the empty field case.
> :Defense: It is necessary to have a terminator since codetags may be
>     followed by non-codetag comments.  Or codetags could be limited to
>     a single line, but that's prohibitive.  I can't think of any
>     single-character terminator that is appropriate and significantly
>     better than <>.  Maybe ``@`` could be a terminator, but then most
>     codetags will have an unnecessary @.

The <> terminator is evil.  People will hate that. If there are no fields,
you should just be able to leave it off. This will have an additional
advantage in that many will already have compliant codetags if you leave
off this requirement.

You worry over the need to detect the end of the block, but wouldn't '\n\n'
be a much more natural delimiter?  I.e.:

# TODO: This is a multi-line todo tag.
#       You see how I've gone to the next line.

# This, on the other hand is an unrelated comment. You can tell it's not
# related, because there is an intervening blank line.  I think people
# do this naturally when writing comments (I know I do -- I'm fairly
# certain I've seen other people do it).
# Whereas, as you can see, a mere paragraph break can be represented by
# a blank comment line.
# Whitespace formatting, after all, is VERY PYTHONIC. ;-)
# Delimiters on the other hand -- well, we prefer not to mention
# the sort of languages that use those, right? ;-)

Another possibility is to recognize lines like:


I.e. a comment mark followed by a line composed of repeating characters
as an alternative separator. These are also pretty in pretty common


Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

More information about the Python-Dev mailing list