Confused about pep 318

[Edward K. Ream]

Hello all,

First of all, my present state of mind re pep 318 is one of sheepish
confusion.  I suspect pep 318 will not affect Leo significantly, but I am
most surprised that an apparently controversial feature is being added
without a notice, say, in comp.lang.python.announce.  I say sheepish,
because everyone knows that one should make sure new proposals don't bite
you.  Still, I would have thought that there were other ways of keeping
abreast of potentially major changes to Python besides reading py-dev...

The following are some comments to recent posts on py-dev.  I hope to convey
by these remarks my sense of bewilderment.

> There is little point in going over all the same arguments again and
again. For this alpha release, no amount of arguing will change what has
been committed. You really have to organize a public outcry if you want the
syntax changed before 2.4. [Martin v. Löwis]

I'd like to defer the question of a "public outcry" until later, hopefully
much later.

But I have no idea what the proposed syntax is(!!) In particular, there is
no mention of '@' directly on the page
http://www.python.org/peps/pep-0318.html

Is there a summary of recent work?  An announcement?  Some indication of
consensus?

> > In general, I predict most Python code will continue to be blissfully
unadorned with decorators.

> Right.  Outside the test suite, there are very few uses of classmethod,
staticmethod and property in the standard library. GvR

Hmm... I see nowhere in pep 318 any mention that the pep will affect the
following section of the Reference manual:
http://docs.python.org/ref/delimiters.html

[quote]
The following printing ASCII characters are not used in Python. Their
occurrence outside string literals and comments is an unconditional error:
@       $       ?
[end quote]

I would regard any change to this paragraph as a major change to Python, in
spite of its innocent appearance.   Indeed, this paragraph is an excellent
"line in the sand" for other tools.

To repeat, I suspect adding @ would not affect Leo significantly in any
direct way, and a workaround would probably exist even if it did.  However,
this proposal probably would affect the noweb markup language on which Leo
is (loosely) based.  See http://www.eecs.harvard.edu/~nr/noweb/

BTW, a long while back I suggested that there was no reason for the parser
to need colons after "if" statements, etc.  The response was: true, but
allowing colons to be elided would impact existing tools.  So I gave up.  Am
I the first to suggest that allowing '@' characters in valid Python programs
outside string literals and comments might negatively impact existing tools?

> Sigh.  This discussion is going around in pointless circles; we're
*months* past that point.  You're wasting your time (and mine). [GvR]

I confess that I don't understand this remark at all.  How has it happened
that so many people are confused about this proposal?  And if everything is
so clear, why isn't the clarity reflected in pep 318 itself?

http://www.python.org/peps/pep-0318.html talks about

- Background
- Design goals
- Proposed syntax (no mention of @!)
- Alternative proposals
etc.

Excuse me, but if everything is now set in stone, then this is an
extraordinarily misleading document.

> Sorry.  I think you'd be wise to consider the months without consensus as
evidence of a problem. [Jim Fulton]

This is my present opinion as well.

Summary

I wish to disavow any knowledge, or any interest in, the wider issues of
whether pep 318 is a good idea or not.  My concern is exclusively with the
following two issues:

1.  IMO, allowing '@' in valid Python programs (outside string literals or
comments) is a major change to the language that has significant potential
to disrupt already existing tools.  At the very least, some discussion of
http://docs.python.org/ref/delimiters.html should be in pep 318.

2.  pep 318 apparently does not reflect the present state of affairs, and
afaik there has been no announcement of proposed changes on
comp.lang.python.announce.  This is disturbing.  If anyone could clarify the
present status of pep 318 I would be most grateful.  I would prefer not to
be told to read all the py-dev archives.  If everything is now clear, where
can I find out about it?

Edward
--------------------------------------------------------------------
Edward K. Ream   email:  edreamleo at charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------