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

[Stephen Horne]

On Wed, 24 Mar 2004 17:22:31 -0700, David MacQuigg <dmq at gain.com>
wrote:

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

>>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.

So each statement will only ever be extended once, and for one
purpose?

>
>>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').

If it's a secondary syntax, learned late and rarely used, then a long,
explicit keyword is just what is needed. You can look it up, of
course, but it is far better for readability if you don't need to - if
the explicit keyword is itself a sufficient reminder. After all, it's
not just newbies that we should worry about - what about people like
me, who use several languages and sometimes go months without using
Python at all?

As for the print statement, I wouldn't use a decorating approach at
all. And neither did you, for that matter - what you described could
not be implemented using decorator functions.


What I might use is something like...

  pragma printoptions ( separator = ' ', terminator = '\n' ) :
    print "whatever"
    print "something else"

...as a general way of providing standard-behaviour-overriding flags
for built-ins.

Except that I don't see this as a real problem. Print works well as a
quick way to get results out of short scripts, where perfect
formatting of those results is unimportant. In more sophisticated
programs, other I/O mechanisms are better suited to the job.

>>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 [] ).

If a statement has a 'decorators' extension syntax, it can always add
a 'widget' or 'blodget' extension syntax later, being clear to both
the parser and the reader.

Contrast the case with a single extension-denoting symbol - '$'
perhaps. If it gets re-used for several extensions to the same
statement, you get the real possibility that the only way to tell the
different extensions apart is the ordering. Which, at the very least,
means a far greater probability of having to reread the documentation
to figure out what something means - ie bad readability.

>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.

So do I - that is why I suggested a preamble method, where the list of
decorators to apply to a whole group of functions is only written
once.


-- 
Steve Horne

steve at ninereeds dot fsnet dot co dot uk