"as" keyword woes

[Warren DeLano]

> > Why was it necessary to make "as" a reserved keyword?
> 
> I can't answer for the Python developers as to why they *did* make it
> a reserved word.
> 
> But I can offer what I believe is a good reason why it *should* be a
> reserved word: Because simple is better than complex, and special
> cases aren't special enough to break the rules.

So you prefer broken code to broken rules, eh?  Your customers must love
that!  This is exactly the kind of ivory-tower thinking I feared might
be behind the decision (form over function, damn the users to hell,
etc.)

> > And more to the point, why was it necessary to prevent developers
> > from being able to refer to attributes named "as"?
> 
> There aren't special rules for which names can be use in which way,
> and that's a *good* thing. Any name that is valid in one area of
> Python syntax is valid in all Python syntax.

Except that Python syntax has proven itself to be a non-backwards
compatible moving target.  Eliminating cruft and adding new
functionality is one thing, but introducing a whole new two-letter
keyword so long after the game has begun?  That seems well over the line
of what can be considered reasonable.

> > Why can't the parser distinguish between a standalone " as " keyword
> > and ".as" used as an object/attribute reference?
> 
> Because that would require special-casing some names as being
> forbidden in syntax where other names are allowed. Special cases in
> language syntax are to be avoided where feasible.

Am I the only one picking up on the irony here?  "as" exists largely to
provide a mechanism for working around namespace conflicts -- except,
apparently, conflicts involving "as".  The fact that "as" itself creates
an insurmountable namespace collision is just killing me!  How absurd.

Anyway, it seems obvious that the right decision for our customers (or
more importantly, for their countless lines of autogenerated-Python log,
state, and code files from the past decade) is to stick with C/Python
2.5.x for the time being and plan to make the jump to a threads-capable
and hopefully backwards-compatible Python implementation as soon as
possible (IronPython perhaps?).   That seems like a sensible path around
the breakage and enduring limitations of C/Python 2.6 or 3.

Or in other words, if we're all going to go through a Python
compatibility-disconnect, then we might as well kill as many birds as
possible in a single pass -- and that single-threaded interpreter bird
is definitely a "dodo" in danger of extinction.

By the way, congratulations on 3.0 final!  

But to be brutally honest...in this many-core world we must all accept
and deal with today, it is hard to imagine how a non-multithreaded AND
non-backwards compatible Python implementation can have much of a life
ahead of it, with or without an "as" keyword.  I do sincerely hope I am
wrong about this, but it is seems quite possible that C/Python's glory
days are now behind us.  

And if so, then thank you all for so many wonderful years of effort and
participation!  C/Python has had a great run, and Python syntax, in a
multiplicity of forms, will surely live on for many decades to come.
Python has changed the world, and very much so for the better.  

Well done!

Cheers,
Warren