Python 3.0 - is this true?

[Duncan Grisby]

In article <mailman.4252.1227113353.3487.python-list at python.org>,
Terry Reedy  <tjreedy at udel.edu> wrote:

[...]
>> l = []
>> for line in open("bigfile.txt"):
>>     x = random.randint(0,100)
>>     if x < 4: l.append(None)
>>     else: l.append(line)
>
>So use '' or '\0' instead of None for null lines.  Or replace None for 
>the sort.

Both '' and '\0' could conceivably be valid data values. The problem
is that the data comes from a dynamically-typed database, so there is
no guarantee what the data values might be. This for loop with a file
is just an example that generates similar-looking data. It bears no
relation to the way the data is actually acquired.

>> And maybe once in a while you end up with something not dissimilar to:
>> 
>> l = []
>> for line in open("bigfile.txt"):
>>     x = random.randint(0,100)
>>     if x < 4: l.append(None)
>>     elif x < 5: l.append([line,line])
>>     else: l.append(line)
>> 
>> In that kind of case it doesn't really matter what happens to list
>> items in the sort order, but it's important it doesn't fail to sort
>> the ones that are strings.
>
>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.

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.

Cheers,

Duncan.

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