The problem with "as" [was "Re: PEP 318"]

[David MacQuigg]

On Wed, 24 Mar 2004 09:48:00 +0000, Stephen Horne
<steve at ninereeds.fsnet.co.uk> wrote:

>On Tue, 23 Mar 2004 18:40:07 -0700, David MacQuigg <dmq at gain.com>
>wrote:
>
>>Beginners will learn very quickly that the special symbol
>>means "similar to the standard syntax, but RTFM if you don't yet know
>>this variation".
>
>RTFM doesn't really work when you don't have a keyword to look up.

The extension syntax is *always* associated with a statement.  The
documentation on the extension is at the end of the section on that
statement.

>Symbols (and worse, odd combinations of symbols where it's hard to
>tell which symbols are part of the same syntax rule and which are not)
>that you've not seen before tend not to suggest where in the manual to
>look.

We need a single unique symbol, one that doesn't conflict with
existing syntax, and has no special meaning itself.  By using this
symbol for extensions of *many* statements, we minimize the amount of
new words or syntax users have to learn.

>If 'as' is too generic, then what about 'decorators'. That clearly
>states what follows and can easily be looked up, making the 'RTFM'
>attitude justifiable.

"Decorators" is clear as to its meaning, but a little too long,
especially if it causes statments with multiple decorators to run over
one line.  It also limits the syntax to this one statement.  You would
not want to extend the syntax of a print statement, for example, with
decorators=(separator = ' ', terminator = '\n').

>OTOH, there is the 'def' keyword for people to look up already in this
>case.

Exactly.  All the syntax has to say is "This is an extension of the
def statement."

>>Does it make sense to have a general symbol for modifications of the
>>simple standard syntax?
>
>Not really. What happens when there are two different ways of
>modifying the same syntax? When the first one was defined with no
>awareness that another kind of modification might be needed later?

I guess I'll need an example here.  Seems like the potential for
future incompatibilities is *greater* if the syntax itself has
"special meaning" ( e.g. "decorators" instead of [] ).

>My opinion is that it is better to try to avoid symbols and
>over-generic keywords, and to try to be more explicit about what the
>modification actually is (in this case, decorators). Particularly
>where the syntax may be infrequently used.
>
>Of course short is sweet too. Easy answers are very rare.

I would favor short in the case of decorating def statements.  Even if
we use syntax unique to this statement (e.g. [] ) it seems pretty
clear this is a modification of a normal def.  The symantic burden is
carried by the decorator names, which can be as explicit as you like.
Also, I think in programs where the syntax is useful, it will be used
a lot, so ease of typing and readability is an issue.

We just need to avoid the Perl problem.  We can do that by not using
different symbols for extending different statements.

-- Dave