Extending Python Syntax with @

[David MacQuigg]

On Wed, 10 Mar 2004 15:31:12 -0600, Jeff Epler <jepler at unpythonic.net>
wrote:
>I don't like your suggestion.  You propose using @ in 4 different
>ways, one of which I don't even understand
>    -- to pass keyword arguments to statements
>    -- instead of the perfectly good "lambda" keyword
>    -- mumble generators mumble (this is the example I don't understand)
>    -- instead of the perfectly good "self." idiom

The details of these suggestions don't matter.  The key concept, which
nobody seems to appreciate, is that we can *avoid* different and
confusing ways of extending an existing syntax.  Perhaps a better
example will help.

Paul Prescod in a recent thread proposed deprecating the print
statement in favor of a "show()" function.  The new function would
provide the same defaults as our current print statement, but would
also allow changing those defaults via keyword arguments.  As you
might expect there were lots of objections to deprecating the existing
syntax.  The arguments in favor were good, however, and I could see
this being done in some future version of Python.

There are lots of other examples where it would be nice to extend the
current syntax without changing the old.  So how would we do that with
the print statement?  We could do it by adding keywords, like was done
did with 'lambda' and 'yield'.  That seems to be the implication of
the arguments in this thread against using a special symbol.

What I'm saying is, rather than add new keywords, it would be better
to have a standard symbol that has no specific meaning other than
"modify this statement".  Beginners will learn the basic statements,
and ignore the modifications.  Later they will see an @ symbol on some
otherwise familiar statement, and they will go to the docs for that
statement to figure out what it means.  This is quite different than
Perl, where symbols themselves convey many complex meanings.

Maybe there will be no more changes in Python. I think that would be a
mistake as bad as adding more unnecessary keywords for seldom-used
statements.

-- Dave