alex23 wrote:
On Dec 4, 3:42 pm, "Warren DeLano" <[EMAIL PROTECTED]> wrote:
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.)
Really? I find that believing something should remain static at the
expense of actual improvement to the language is far more 'ivory-tower
thinking' than embracing change.
First, to quote Tim Peters, "practicality beats purity." Second, I might
be biased here because I happen to know Warren, but, although he hails
from the ivory tower, I imagine his concerns are purely practical. His
contributions to software in structural biology are legendary.
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.
Speaking of irony, you're complaining about namespace conflicts with a
-two character identifier- you've chosen. Here's a hint: choose better
names.
The name fit his needs until changes in the language broke the name. If
a name works and the code works, then the name is good enough. And
speaking as a professional user of his software at the level of the
application and at the level of the API, let me tell you his code works
pretty damn good.
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.
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?
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.
Correction: Real programmers write programs. And no, at this point he
can't do anything but complain because, as others have noted, the change
is not going away.
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.
You probably aren't a developer for the cPython implementation, but, if
you were, I'd recommend taking rants like Warren's to heart because they
are born of honest frustration and practical concern. Hopefully
developers for python 2.7 are listening and won't break backward
compatibility just because the "Zen of Python" suggests it might be a
good idea.
James
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
http://www.jamesstroud.com
--
http://mail.python.org/mailman/listinfo/python-list
