"as" keyword woes
Eduardo O. Padoan
eduardo.padoan at gmail.com
Thu Dec 4 12:25:50 CET 2008
On Thu, Dec 4, 2008 at 7:44 AM, James Stroud <jstroud at mbi.ucla.edu> wrote:
> 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,
>> 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
> 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
>> 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.
Even I, who am not, by really far, legendary on anything, could give
my 2¢ one time or another on python-dev or python-ideas. If you really
care and think you have a good argument, I'm sure you are welcome to
post there! But they cant hold the release until everyone in the world
have voiced his concerns, its just not pratical.
Eduardo de Oliveira Padoan
"Distrust those in whom the desire to punish is strong." -- Goethe,
More information about the Python-list