On Thu, Dec 4, 2008 at 7:44 AM, James Stroud <[EMAIL PROTECTED]> wrote: > 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.
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 -- http://mail.python.org/mailman/listinfo/python-list