New statement proposal for Python

[Tim Peters]

[Alex Martelli]
> ...
> I think the proposed 'yield' is the first new keyword that stands
> a chance of making it into Python in MANY years -- it does meet both
> key criteria (truly major, no real semi-decent alternative).

I like to repeat this every two years or so <wink>:  four keywords have been
added to Python, but only one after 1.0 was released (in January of 1994),
and very few knew that another one existed.

First "exec" was changed from a builtin function to a statement.  This was
done because exec can create new local vrbls, and it was impossible to get
the scoping straight in all cases without letting the compiler know exactly
when an exec could happen (BTW, a similar argument applies to yield wrt
Jython, although Guido lacked the foresight to make yield a builtin function
before 1.0).

"lambda" was added for the 1.0 release.  Guido still regrets it <0.9 wink>.

"access" was added sometime or other, but it was never documented, never
advertised, rarely admitted, and eventually went away again(!).  It was a
gimmick for adding piles of visibility controls to class and instance
attributes; the implementation was terribly complicated, so failed the "if
the implementation is hard to explain, it's a bad idea" test, and Guido
never felt happy enough with it to admit its existence in public.

That leaves the only post-1.0 addition, "assert".  It took years to get that
in -- although it's hard now to remember exactly why.  The primary reason
it's a keyword is so the compiler can eliminate it under -O.

Guido should have made "keyword" a keyword too.  Then we could have had a
keyword statement at the top of each module, identifying all the post-1.0
keywords your code wants to use <0.9 wink>.

> 'alias', IMHO, has _less_ chance than a snowball in hell (the latter
> *might* happen to end up in one of the _frozen_ circles, after all!).
> But note that channeling Guido is NOT my specialty -- gotta ask the
> timbot for that.

I'm not sure that the Dutch vision of hell coincides with Dante's, so in the
interest of not ruffling any international feathers, I'll just say it stands
about as much chance as a drunken virgin in Amsterdam.

Almost all Python code "spells a constant" via

    UPPERCASE_NAME = some_expression

and in 10+ years of Python practice I've never rebound such a name by
accident -- or heard of anyone else doing so either.  This isn't C, and e.g.
we don't have the

    if (OOPS = 3)

flavor of accidental rebindings.  Neither does Python have pointers or an
address-of operator, nor a call-by-reference mode, etc.  You just can't put
a name in a binding context by accident in Python, except for stumbling into
the

    except ValueError, OverflowError:

wart, and UPPERCASE_NAME is very unlikely to appear in that context.

"const frameworks" get invented routinely, but their inventors appear to
drop them after the heat of argument fades.  Why bother?  A universal
convention supplies all of maintainability, clarity, consistency, and a
foundation for good programming habits too.  What it doesn't do is insist
that you follow it against your will.  That's Python!

Guido once said that protection mechanisms in Python are like bicycle locks
in Amsterdam:  they're advisory.  If you're not working with reasonably
mature consenting adults, look into the rexec and Bastion modules for ways
to *really* frustrate your errant coworkers.  If you can't trust *yourself*
to adhere to simple conventions, though, Python isn't your language.

otoh-keep-using-it-and-you'll-change-so-that-it-is<wink>-ly y'rs  - tim