PEP scepticism

Tim Peters at
Fri Jun 29 23:43:34 CEST 2001

[phil hunt]
> 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"?

It's like judging pornography:  "contemporary community standards".  If you
have to ask, you're either a pornographer or a juror <wink>.

> 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)?

Separate PEPs are much more visible.  Like the Answer to Everything, PEP 42
may be a long time coming.

> It seems to me that optional-pass is obvious in its meaning,

Sorry, I have no idea what it means.  Like you want to be able to use "pass"
in more places, but optionally?  Or want not to have to use pass in some
places where you must use it now?  Or ...?

> but multi-liner comments aren't. There are three issues:
> 1. what should be the character sequences to begin/end multi
> line comments

What do you have against the existing method?  That is,

    """This is a multi-line comment.
    this part of the same comment.
    so is this."""

It's truly a comment:  a statement consisting of just a string is thrown
away by the compiler, unless it's in a docstring position (is the first
non-comment statement in a module, def or class).

Or the other existing method:

    # This is a multi-line comment.
    # Although it sure looks like a sequence of
    # single-line comments <wink>.

There's really no point answering these questions on  that they've
been *asked* means the proposals are already controversial, so need PEPs to
lay out all sides of the case.  I don't know what "optional pass" means, but
the multi-line comment business has come up many times, so it would be
especially good to PEP that one, in order to lay it to rest (one way or
another) for good.

More information about the Python-list mailing list