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

[David MacQuigg]

[Stephen Horne]:
>>>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.

[David MacQuigg]:
>>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.

[Stephen Horne]:
>So each statement will only ever be extended once, and for one
>purpose?

[David MacQuigg]:
Using a symbol to introduce an extension doesn't mean we can't add
more extensions later.  If we extend the def statement now with
$(staticmethod), that does not mean we can't later add $(accepts(int,
int), returns(float)) If the concern is flexibility for future
extensions, I would think we should *avoid* keywords like 'as' which
tend to *limit* the options.  Note: The keywords in the $(...) phrase
are keywords *only* within this context, and do not limit the
extension as a whole.  Within this limited context, we can be as
descriptive as we want with each keyword.  A quick review of the
discussion on PEP 318 shows quite a collection already (staticmethod,
classmethod, onexit, singleton, accepts, returns, generator, ...).

[Stephen Horne]:
>>>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.

[David MacQuigg]:
>>"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').

[Stephen Horne]:
>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.

[David MacQuigg]:
The place for specific keywords is *inside* the general extension
syntax.  There we have no restrictions on how specific we can get.

[Stephen Horne]:
>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?

[David MacQuigg]:
Our goals are the same.  My clients are some of the best IC designers
in the world, but they don't have time to learn another computer
language.  What I can't pack into a two-day course on Python, I want
to "encapsulate" in a way that will not cause confusion later.  I
expect they will learn the basic syntax on most of the Python
statements, but not the extensions.  My "common-symbol-for-a
statement-extension" proposal is a way to encapsulate complexity.
Even if users never learn what is a 'generator', when they see that
word as part of a common extension syntax on a def statement, they
will not be discouraged from reading the def as they would a normal
function.

I think my recent experience in learning Python is typical of what we
can expect from IC designers.  I was put off by statements like
"lambda", "yield", "staticmethod", even though from a users view, they
are not fundamentally different than the basic statements.  Instead of
making lamda functions look like something new and wierdly different,
and mystifying the discussion with references to lambda calculus, it
would have been much better to use the standard function syntax and
substitute a "modified syntax" symbol for the function name.
Unglamorous, but very practical.  The explanation would take about two
sentences, and a simple example of its use would be about a half-page.

I have high hopes for Python.  If it continues to evolve in the right
direction, I can see it becoming the ultimate computer language for
non-programmer technical professionals.  I've looked also at Ruby, and
I see that as the second most likely to become the ultimate language.
With a five-year hindsight advantage over Python, it has some
syntactic benefits, but it just doesn't have yet the critical mass of
libraries and general support enjoyed by Python and Perl.

[Stephen Horne]:
>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.

[David MacQuigg]:
I think I'm using the word 'decorator' in a more generic sense -
anything that 'decorates' or 'adds to' the basic syntax of a
statement.

[Stephen Horne]:
>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.

[David MacQuigg]:
I like this.  It keeps the basic syntax of the print statement clean.
It avoids a lot of typing in situations where there is a repetition of
the same 'decoration' on many statemtents.  The main drawback I see is
that in many situations, the modifcation is 'one time only'.  Then we
have *three* statements instead of one. ( We need a statement to
restore the default printoptions.)

Using the "common-symbol-for-a statement-extension" syntax, we could
modify multiple statements without too much clutter using something
like:

opts = printoptions( separator = ' ', terminator = '\n' )
print @(opts) "whatever"
print @(opts) "something else"

[Stephen Horne]:
>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.

[David MacQuigg]:

sys.stdout.write('%s %s %s\n' % (x, y, z) )

is enough of an inconvenience that many users are pushing for
something more.  And when each extension is added, like 'print >> ...'
there are howls of protest from those who see it as a wart.  Wouldn't
it be better if we introduce just one 'wart', a new symbol, that can
be used to solve this and many other problems.  >> is a wart only
because it is unique to this one situation.  If we use a syntax that
solves many similar problems, it becomes a feature, not a wart.

[Stephen Horne]:
>>>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?

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

[Stephen Horne]:
>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.

[David MacQuigg]:
So to make the example more concrete, I assume you would do something
like:

def func1( x, y, z ) decorators(staticmethod), blodgett(gradoo):

instead of:

def func1( x, y, z ) [staticmethod, gradoo]:

I think I'm missing something.

[Stephen Horne]:
>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.

[David MacQuigg]:
I would expect the def statement to grow the most number of extensions
[staticmethod, accepts(int, int), ...].  Even with dozen or more,
surely we can name them distinctly.

Hey - I appreciate your time in giving these issues some real thought.

-- Dave