Re: no more comparisons

2008-03-13 Thread Alan Isaac
Dan Bishop wrote: > Even assuming you meant (-x[0], int(x[1])), that sorts negative > numbers in the wrong order. You want > key = lambda x: (-1 if x[0] else 1) * int(x[1]) Sorry, was speed typing (very badly) and the question actually had two different problem descriptions. As you su

Re: no more comparisons

2008-03-13 Thread Mark Dickinson
On Mar 13, 8:38 pm, Alan Isaac <[EMAIL PROTECTED]> wrote: > Does this do it? :: > >     key= lambda x: (-x[1],int(x2)) > > Here I am depending on the lexicographic sorting of tuples. > Without that there would be real trouble. Close. :-) I think it needs to be something like: key = lambda x: (-x

Re: no more comparisons

2008-03-13 Thread Dan Bishop
On Mar 13, 7:38 pm, Alan Isaac <[EMAIL PROTECTED]> wrote: > Mark Dickinson wrote: > > Sorting tuples, where the second item in the tuple should > > have the opposite ordering to the first is going to be > > a bit of a pain. Or even worse, where the ordering of the > > second item depends on the va

Re: no more comparisons

2008-03-13 Thread Alan Isaac
Mark Dickinson wrote: > Sorting tuples, where the second item in the tuple should > have the opposite ordering to the first is going to be > a bit of a pain. Or even worse, where the ordering of the > second item depends on the value of the first item in the > tuple. This is like some

Re: no more comparisons

2008-03-13 Thread Mark Dickinson
On Mar 13, 5:10 pm, Mark Dickinson <[EMAIL PROTECTED]> wrote: > (1, '14') represents 14 should be -14, of course. -- http://mail.python.org/mailman/listinfo/python-list

Re: no more comparisons

2008-03-13 Thread Mark Dickinson
On Mar 13, 3:48 pm, Alan Isaac <[EMAIL PROTECTED]> wrote: > So maybe this is not as bad as I feared.  What are some use > > cases that will clearly be harder (i.e., at least require > > a slightly elaborate wrapper) after this change? Sorting tuples, where the second item in the tuple should have

Re: no more comparisons

2008-03-13 Thread Alan Isaac
>> Dan Bishop wrote: >>> def cmp_key(cmp_fn): >>>class CmpWrapper(object): >>>def __init__(self, obj): >>>self.obj = obj >>>def __cmp__(self, other): >>>return cmp_fn(self.obj, other.obj) >>>return CmpWrapper > On Mar 13, 12:38 pm, Alan

Re: no more comparisons

2008-03-13 Thread Carl Banks
On Mar 13, 12:38 pm, Alan Isaac <[EMAIL PROTECTED]> wrote: > Dan Bishop wrote: > > def cmp_key(cmp_fn): > > class CmpWrapper(object): > > def __init__(self, obj): > > self.obj = obj > > def __cmp__(self, other): > > return cmp_fn(self.obj, other.obj) > >

Re: no more comparisons

2008-03-13 Thread Alan Isaac
Dan Bishop wrote: > def cmp_key(cmp_fn): > class CmpWrapper(object): > def __init__(self, obj): > self.obj = obj > def __cmp__(self, other): > return cmp_fn(self.obj, other.obj) > return CmpWrapper Apparently I'm overlooking something obviou

Re: no more comparisons

2008-03-13 Thread Duncan Booth
Paul Rubin wrote: > "Terry Reedy" <[EMAIL PROTECTED]> writes: >> | I don't see what's so inefficient about it necessarily. >> >> The key function is called once per list item, for n calls total. >> The comparision function is called once per comparision. There are >>

Re: no more comparisons

2008-03-12 Thread Terry Reedy
"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message news:[EMAIL PROTECTED] | "Terry Reedy" <[EMAIL PROTECTED]> writes: | > | I don't see what's so inefficient about it necessarily. | > | > The key function is called once per list item, for n calls total. The | > comparision function i

Re: no more comparisons

2008-03-12 Thread Paul Rubin
"Terry Reedy" <[EMAIL PROTECTED]> writes: > | I don't see what's so inefficient about it necessarily. > > The key function is called once per list item, for n calls total. The > comparision function is called once per comparision. There are at least > n-1 such calls and typically something on

Re: no more comparisons

2008-03-12 Thread Dan Bishop
On Mar 12, 6:52 pm, Alan Isaac <[EMAIL PROTECTED]> wrote: > Paul Rubin wrote: > > The cmp option should not be removed. However, requiring > > it to be specified as a keyword parameter instead of just > > passed as an unlabelled arg is fine. > > Sure; I would have no problem with that. > > But tha

Re: no more comparisons

2008-03-12 Thread Terry Reedy
| > Hmm, wasn't aware they were taking it that far. You should almost | > always avoid using the cmp parameter because it's very inefficient; | | I don't see what's so inefficient about it necessarily. The key function is called once per list item, for n calls total. The comparision function is

Re: no more comparisons

2008-03-12 Thread Alan Isaac
Paul Rubin wrote: > The cmp option should not be removed. However, requiring > it to be specified as a keyword parameter instead of just > passed as an unlabelled arg is fine. Sure; I would have no problem with that. But that is not what is happening. As for Carl's suggestion to use ``k

Re: no more comparisons

2008-03-12 Thread Paul Rubin
Carl Banks <[EMAIL PROTECTED]> writes: > > For example:http://www.python.org/dev/peps/pep-3100/ > > list.sort() and builtin.sorted() methods: eliminate cmp parameter > > [27] [done] > > Hmm, wasn't aware they were taking it that far. You should almost > always avoid using the cmp paramet

Re: no more comparisons

2008-03-12 Thread Carl Banks
On Mar 12, 4:51 pm, Alan Isaac <[EMAIL PROTECTED]> wrote: > I was surprised to see that > comparison is slated for death > in Python 3000. > > For example:http://www.python.org/dev/peps/pep-3100/ > list.sort() and builtin.sorted() methods: eliminate cmp parameter > [27] [done] Hmm, wasn'

no more comparisons

2008-03-12 Thread Alan Isaac
I was surprised to see that comparison is slated for death in Python 3000. For example: http://www.python.org/dev/peps/pep-3100/ list.sort() and builtin.sorted() methods: eliminate cmp parameter [27] [done] But there is a rumor of a PEP to restore comparisons. http://mail.python.org/pipe