"as" keyword woes

[James Stroud]

alex23 wrote:
> On Dec 4, 3:42 pm, "Warren DeLano" <war... at delsci.com> 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