"as" keyword woes

[Eduardo O. Padoan]

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,
>>> 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.


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
http://djangopeople.net/edcrypt/
"Distrust those in whom the desire to punish is strong." -- Goethe,
Nietzsche, Dostoevsky