PEP scepticism

[phil hunt]

On Fri, 29 Jun 2001 11:50:13 -0400, Barry A. Warsaw <barry at digicool.com> wrote:
>
>>>>>> "ph" == phil hunt <philh at comuno.freeserve.co.uk> writes:
>
>    ph> Is there a PEP for multi-line comments?
>
>    ph> Or one for making ``pass'' optional?
>
>Nope, so obviously no one thought there was enough controversy or need
>in either of these two areas.
>
>The only requirements for PEP authors is that you have some ability to
>write well, can communicate your ideas clearly and succinctly, and
>that you be open to criticism and discussion from the community.  IOW,
>almost /anybody/ can be a PEP author.
>
>If you think multiline comments or optional-pass are subjects worthy
>of PEP-hood, follow the guidelines in PEP 1 and submit your own
>offerings!

Now there's a challenge!

PEP1 says:
   The PEP champion (a.k.a. Author) should first
   attempt to ascertain whether the idea is PEP-able. 
    Small
    enhancements or patches often don't need a PEP and can be injected
    into the Python development work flow with a patch submission to
    the SourceForge patch manager[2] or feature request tracker[3].

How do I ascertain this? 

Who decides whether something is a "small enhancement"?

The changes i propose would be two separate PEPs (I assume) --
or would they be added to PEP-42 (which is a list of small 
features)?

It seems to me that optional-pass is obvious in its meaning,
but multi-liner comments aren't. There are three issues:

1. what should be the character sequences to begin/end multi
line comments

I propose /* to start multi-line comments and */ to
end them. Eg:

/* this is a multi-line comment.
this is part of the samer comment.
so is this. */

Rationale: similar to C and many other languages; the combination
/* isn't legal anywhere in current python code (AFAIK) so won't
break it. I did consider using one of @$? which are not currently
used by python, but it's best to leave these unused so they
are still available for extra operators (or whatever) at a later
date.

2. how will this interact with python's indent/dedent mechanism

In particular, how do we treat this:

def myfunction():
   print "hello"
   print "start" /* start of comment
middle of comment
end of comment */   print "goodbye"

IMO the best way to prevent unexpected wierdness like this is
to forbid any code in any line after the */ closing-comment
sequence; or perhaps to give a warning and ignore it (it
shouldn't just be silently ignored, as this will confuse people
familiar to how it works in C).

3. will it break any old code

AFAIK my proposal as it stands won't.



-- 
## Philip Hunt ## philh at comuno.freeserve.co.uk ##