Confused about pep 318

[Edward K. Ream]

> As in many other software efforts, the code has moved along a bit
> faster than the documentation (after all, what's more fun to do?).
...
> Guido indicated there that he brought up the topic at
> EuroPython in his keynote talk and entertained discussion from the floor.
> Based upon that discussion he decided to go with the @-decorator syntax.

Well, this isn't good.  We are talking about a basic design document here.
I feel like I have been kept in the dark; my previous relative silence is
hardly evidence of my agreement.  How is it possible to pretend that people
agree with a proposal that DOES NOT EXIST?  I am -10 on pep 318 now: this
process amounts to a rigged election.  I might become neutral in the future
once the hood is removed from over the candidate's head :-)

> I believe the only significant differences from a pure functional
> documentation standpoint to apply to the PEP are the syntax

Why is something "spectacular" like the '@' sign is needed?  Presumably
there is some problem with the compiler?  Has anyone suggested something
like:

from __future__ import annotation as annotate

annotate.accepts(int, (int,float))

instead of:

@accepts(int, (int,float))

Clearly, with enough work the Python compiler could recognize this.  Yes,
it's a special case, but so what?  This would avoid most problems with
reserved words or keywords.  And it would be in the spirit of letting
modules encapsulate most major features.

Edward

P.S. The more I think of this proposal, the more unhappy I become.  In fact,
this proposal may have a most unfortunate effect on Leo's future, for two
reasons:

1. Although Leo handles constructs like @accepts, it does so by generating
lines like this:

#@verbatim
@accepts(int, (int,float))

So _Leo_ has no problem, but Leo's users will likely complain that more
cruft has been added to their files.

2. Leo presently supports the following directives:

@ (followed by one or more whitespace characters)
@all, @asis,
@c, @code, @color, @comment,
@delims, @doc,
@encoding, @end_raw,
@file, @first,
@header,
@ignore,
@killcolor,
@language, @last, @lineending,
@nocolor, @noheader, @noref, @nosent, @nowrap,
@others,
@pagewidth, @path,
@quiet,
@raw,
@root, @root-code, @root-doc,
@silent,
@tabwidth, @terse, @thin,
@unit,
@verbose,
@wrap

Worse, Leo allows plugins to define their own directives.  There is already
a plugin that defines @wiki.  Furthermore, @run, @test and @suite are also
used in special contexts.

What happens when another Python @x construct conflicts with one of these
directives or some other directive?  I'm starting to wonder whether Python
is a snake or a gorilla :-)

Yes, Python does have the right to use '@'.  But I would hope that GvR would
choose not to do so. I was always under the impression that the clear
statement in the Reference Manual that at signs are invalid everywhere
(except in comments and strings) was a clear signal of an intention to keep
those symbols for other valid purposes.  I am extremely unhappy that this
may not be so.

P.P.S.  I did respond earlier to the requested survey, saying in brief that
I had no problems with 318 provided that '@' signs did not become a part of
the syntax.  I have received no reply from anyone.  There is no way somebody
could construe my previous statements as approval.

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