Python 3.0 - is this true?

[Duncan Grisby]

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:

[...]
>>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.

You misunderstand me.

My application is not broken. It handles a wide range of data types,
_but they are all sortable_. It doesn't involve any complex numbers.
There is no way a complex number could be stored in the database, so
that is not an issue.

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

My database isn't like a SQL database. It's dynamically typed, just
like Python. The range of types is limited to things that can be
marshalled into the underlying storage, so I can absolutely guarantee
that they are all sortable in Python 2, even though the permitted
range or types is quite wide.

[...]
>>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.

Several people _have_ in fact claimed that I can't possibly have a
hard problem to solve in this respect. In general, the responses can
be grouped into those people claiming that it's trivial to fix, and
those (like you) claiming that it's ok that it's hard to fix because
it's already broken. Neither are true.

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.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --