copysort patch, was RE: [Python-Dev] inline sort option

[Alex Martelli]

On Tuesday 28 October 2003 04:18 pm, Guido van Rossum wrote:
> > Okay, this is the last chance to come-up with a name other than
> > sorted().
> >
> > Here are some alternatives:
> >
> >   inlinesort()   # immediately clear how it is different from sort()
> >   sortedcopy()   # clear that it makes a copy and does a sort
> >   newsorted()    # appropriate for a class method constructor
> >
> >
> > I especially like the last one and all of them provide a distinction
> > from list.sort().
>
> While we're voting, I still like list.sorted() best, so please keep
> that one in the list of possibilities.

I also like list.sorted() -- but list.newsorted() is IMHO even a LITTLE
bit better, making it even clearer that it's giving a NEW list.  Just
a _little_ preference, mind you.  "sortedcopy" appears to me a BIT
less clear (what "copy", if the arg isn't a list...?), "inlinesort" worst.

BTW, I think I should point out one POSSIBLE problem with
classmethods -- since unfortunately they CAN be called on an
instance, and will ignore that instance, this may confuse an
unsuspecting user.  I was arguing on c.l.py that this _wasn't_
confusing because I never saw anybody made that mistake
with dict.fromkeys ... and the response was "what's that?"...
i.e., people aren't making mistakes with it because they have
no knowledge of it.  list.newsorted or however it's going to
be called is probably going to be more popular than existing
dict.fromkeys, so the issue may be more likely to arise there.

Although I think the issue can safely be ignored, I also think
I should point it out anyway, even just to get concurrence on
this -- it IS possible that the classmethod idea is winning "by
accident" just because nobody had thought of the issue,
after all, and that would be bad (and I say so even if I was
the original proposer of the list.sorted classmethod and still
think it should be adopted -- don't want it to get in "on the
sly" because a possible problem was overlooked, as opposed
to, considered and decided to be not an issue).


OK, so here's the problem, exemplified with dict.fromkeys:

d = {1:2, 3:4, 5:6}
dd = d.fromkeys([3, 5])

it's not immediately obvious that the value of d matters not
a whit -- that this is NOT going to return a subset of d
"taken from the keys" 3 and 5, i.e. {3:4, 5:6}, but, rather,
{3:None, 5:None} -- and the functionality a naive user might
attribute to that call d.fromkeys([3, 5]) should in fact be
coded quite differently, e.g.:

dd = dict([ (k,v) for k, v in d.iteritems() if k in [3,5] ])

or perhaps, if most keys are going to be copied:

dd = d.copy()
for k in d:
    if k not in [3, 5]:
        del dd[k]


The situation with list.sorted might be somewhat similar,
although in fact I think that it's harder to construct a case
of fully sympathizable-with confusion like the above.  Still:

L = range(7)
LL = L.sorted()

this raises an exception (presumably about L.sorted
needing "at least 1 arguments, got 0" -- that's what
d.fromkeys() would do today), so the issue ain't as bad --
it will just take the user a while to understand WHY, but
at least there should be running program with strange
results, which makes for harder debugging.  Or:

L = range(7)
LL = L.sorted(('fee', 'fie', 'foo'))

I'l not sure what the coder might expect here, but
again it seems possible that he expected the value of
L to matter in some way to the resulting value of LL.


Perhaps this points to an issue with classmethods in
general, due in part to the fact that they're still rather
little used in Python -- callers of instance.method()
may mostly expect that the result has something to
do with the instance's value, rather than being the
same as type(instance).method() -- little we can do
about it at this point except instruction, I think.


Alex