"as" keyword woes

[Warren DeLano]

> I don't know how you infer any of those from what I said, nor 
> from the process of introducing features in Python. None of 
> what you say there rings at all true with anything I've 
> experienced in Python's core or the attitudes surrounding 
> development if the language; indeed, quite the opposite.

That has been my experience as well, which is why this particular action
seems surprising and out of character.  
 
> Speaking of irony, you're complaining about namespace 
> conflicts with a -two character identifier- you've chosen. 
> Here's a hint: choose better names.

Hey, come on now -- developers working on top of an existing language
bear nowhere near the responsibility as the language & implementation
maintainers.  Also, note that the fields of math and science are filled
with short identifiers with well-defined meanings -- brevity doesn't
mean ambiguous within a given application domain!  But regardless, our
scripts use "as" in the same way as Python -- to change the effective
appearance of an object, albeit in a representational rather than naming
space.  So if we're wrong in our choice, then so is Python.

In addition, note that my choice of a concise method identifier affects
only my users.  Python's introduction of a new keyword affects the
entire Python world code base, so perhaps you should be directing your
"choose better names" criticism in another direction?

> To match your honesty, I'm somewhat tired with the trend of 
> some people to hit -one- issue with Python and suddenly lash 
> out like children over all the same old tired crap. Have you 
> even looked at multiprocessing? Have you contributed to any 
> projects working on GIL- less implementations? Or are you 
> just regurgitating the same bullet points we've heard time 
> and time again?

Multiprocessing solves some problems, but it is unsuitable for
high-frequency handoffs of large (in memory) objects between many
independent threads/processes -- the HPC object/data flow
parallelization model in a nutshell.  

Furthermore, not every coder has the compsci chops to work on language &
VM implementations (my PhD involved programming DNA and directing
evolution in a test tube, not parse trees and state machines).  But that
isn't to say I didn't try: at one point I even sketched out a possible
TLS-based GIL workaround for handling the issue without breaking the
existing C/API.  It was of course shunned by those who knew better...for
performance reasons IIRC.

> For chrissake, if you cannot do ANYTHING but BITCH about a 
> change, then you've no damn right to consider yourself a 
> programmer. Real programmers find solutions, not excuses.

Though I have certainly bitched about the threading issue multiple times
on mailing lists including baypiggies and python-dev, bitching is not
the only thing I've done.  Having come to grips with my own coding
limitations, I also offered to contribute financial resources from my
own Python-enhanced business in support of GIL-removal -- before Python
3.0 was finalized.  Unfortunately, no one responded to my offer.

Even today, I am indirectly proposing the solution of "as" not being a
reserved keyword since it has worked just fine for years without it.
Yes that's late, but I didn't see this particular trainwreck coming
(since it is not actually our current code which breaks, but rather,
quantities of code created years ago but which must still run with
fidelity into the far off future).  Installing a Python macro
preprocessor is another after-the-fact possible solution which may bear
further investigation...

Also today, I am proposing a pragmatic general solution for projects
like ours in addressing both the 2.6/3.0 compatibility and threading
situations.  Specifically: deliberate migration away from C/Python and
on to alternate VMs which happen to support Python syntax.

Obviously none of my past efforts yielded fruit -- but it is wrong and
unfair of you to assume and accuse me of not trying to come up with
solutions.  Solutions are virtually the entire game!

> > And if so, then thank you all for so many wonderful years of effort 
> > and participation!
> 
> You're welcome. Don't let the door hit you on the ass on your way out.

But who's leaving who exactly?  Surely a language as beautiful as Python
will easily transcend the limitations of its flagship implementation (if
or to the extent that such an implementation cannot keep pace with the
times).  That's all well and good -- it may even end up being the next
great leap forward for the language.  I believe Guido has even said as
much himself.

Warren