Python 3.0 - is this true?

Aahz aahz at pythoncraft.com
Tue Nov 25 21:39:34 EST 2008


In article <nIBWk.1525$sn1.226 at newsfe20.ams2>,
Duncan Grisby  <duncan-news at grisby.org> wrote:
>In article <ggegg2$ji8$1 at panix3.panix.com>, Aahz <aahz at pythoncraft.com> wrote:
>>In article <ByvWk.21081$oK4.8230 at newsfe18.ams2>,
>>Duncan Grisby  <duncan-news at grisby.org> wrote:
>>>
>>>For my application, Python 3's comparison behaviour is a backwards
>>>step. You can argue all you like that the new behaviour is the "right"
>>>thing to do, and I'd be inclined to agree with you from a
>>>philosophical point of view, but the fact is that it _will_ cause
>>>problems for existing real code. The particularly ironic thing is that
>>>the database's dynamic typing is closely modelled on Python, including
>>>it's ability to gracefully handle mixed-type lists.
>>
>>What I think people are arguing about is your use of the word "backward".
>>I don't think anyone claims that fixing your application will be trivial,
>>but your application appears to be already broken, and Python 3.0 is
>>simply forcing you to confront it head-on.
>
>The post you've quoted was the first time I used the word "backwards".
>I didn't start this thread, I merely chipped in when people claimed
>there were no real applications that would be affected by this change
>to Python. I do have a real, widely deployed application that will be
>affected. Claiming that it is not affected, or that it is already
>"broken" does not change that fact.

Fair enough; I've been mostly skimming the thread and only your use of
"backward" prompted me to chime in.  ;-)

>This issue is not impossible to deal with, of course, it's just one of
>several things that will mean it's hard for us to migrate to Python 3.
>What I find disturbing is the attitude that this change to Python's
>comparison behaviour can't possibly have any downsides and that anyone
>claiming it does is wrong.

Well, I agree with you that it does make things more difficult in some
respects.  I also think that it's an aggregate improvement that is
similar to the way L.sort() returns None.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan



More information about the Python-list mailing list