Python 3.0 - is this true?

[Aahz]

In article <ByvWk.21081$oK4.8230 at newsfe18.ams2>,
Duncan Grisby  <duncan-news at grisby.org> wrote:
>In article <mailman.4252.1227113353.3487.python-list at python.org>,
>Terry Reedy  <tjreedy at udel.edu> wrote:
>>
>>Replace the sublists with a coded string, such as '\0'+line.
>
>Again, this is just an example. As I say, in the real application, the
>data has come from a dynamically-typed database. There's no easy way
>to coerce all the items to the same type, because the application
>doesn't know up-front what the data is going to look like. In some
>cases, it may be that all the data items are lists of strings. In
>other cases, all or most of the data items will be integers, for
>example.
>
>>If sorting is time (and space) critical, you want a straight string sort 
>>without key *or* cmp function.
>
>That's exactly my point. Currently, the application just builds a list
>of values retrieved from the database and asks Python to sort it. No
>key or cmp function. With Python 3.0, it's going to require a lot more
>work than that.

Unless I misunderstand you, your application is broken already.  Complex
numbers have never been sortable.  If your application works more like a
SQL database, then any given column will have only one datatype and as
long as you avoid types that cannot be compared against themselves
you're safe.

(I'll agree that from some perspectives the new behavior of None is a
wart but I think that in the end I agree with people who say that
preventing None from being sorted except intentionally will trap more
bugs earlier.)

>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.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

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