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