The problem with "as" [was "Re: PEP 318"]
dmq at gain.com
Thu Mar 25 21:48:24 CET 2004
>>>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
>>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
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, ...).
>>>If 'as' is too generic, then what about 'decorators'. That clearly
>>>states what follows and can easily be looked up, making the 'RTFM'
>>"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.
The place for specific keywords is *inside* the general extension
syntax. There we have no restrictions on how specific we can get.
>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?
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
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.
>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.
I think I'm using the word 'decorator' in a more generic sense -
anything that 'decorates' or 'adds to' the basic syntax of a
>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
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
opts = printoptions( separator = ' ', terminator = '\n' )
print @(opts) "whatever"
print @(opts) "something else"
>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.
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.
>>>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.
So to make the example more concrete, I assume you would do something
def func1( x, y, z ) decorators(staticmethod), blodgett(gradoo):
def func1( x, y, z ) [staticmethod, gradoo]:
I think I'm missing something.
>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.
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.
More information about the Python-list