> > 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 -- http://mail.python.org/mailman/listinfo/python-list
