Jeffrey Yasskin wrote:
> For Python, I think I favor reviving __cmp__ for totally ordered
> types, and asking that partially ordered ones return NotImplemented
> from it explicitly.
Returning NotImplemented already means "I don't recognise the other
type". A fully implemented partial ordering is
On 11/17/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > or __cmp__ would
> > have to be extended to support "unordered" as a result.
>
> That's what I think should be done.
Note that this would make it slightly easier to pass a custom sort
function that forced everything to
Martin v. Löwis wrote:
> or __cmp__ would
> have to be extended to support "unordered" as a result.
That's what I think should be done.
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsub
> It'd be simpler still if we only had __cmp__ and __eq__. I just don't
> understand the use cases where that's not sufficient.
>
> Hrm. I guess set's subset checking requires more relationships than
> __cmp__ provides. Abandoning that feature probably isn't an option,
> so nevermind me.
>
> (
On 11/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Everyone who cares about this topic, please collaborate on a PEP. If
> we're going to put __cmp__ back in I'd like to have it in 3.0a2 if at
> all possible. I'd like to release 3.0a2 around mid November. I don't
> personally have much time t
Everyone who cares about this topic, please collaborate on a PEP. If
we're going to put __cmp__ back in I'd like to have it in 3.0a2 if at
all possible. I'd like to release 3.0a2 around mid November. I don't
personally have much time to devote to the topic, but I've seen some
pretty well-motivated
On 10/30/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > for a, b in zip(self.data, other.data):
> > result = richcmp(a, b, ordered)
> > if result:
> > return result
>
> That can't be right, because there are *three*
Steven Bethard wrote:
> If a class defines only __cmp__, Python will do the appropriate
> dance to make <, >, ==, etc. work right. If a class defines only
> __eq__, __lt__, etc. Python will do the appropriate dance to make
> cmp() work right.
With a four-way __cmp__, I wouldn't actually mind if
t
Adam Olsen wrote:
> for a, b in zip(self.data, other.data):
> result = richcmp(a, b, ordered)
> if result:
> return result
That can't be right, because there are *three* possible
results you need to be able to distinguish from compari
Steven Bethard wrote:
> class C(object):
> def __cmp__(self, other):
> if self.foo < other.foo:
> return -1
> elif self.foo < other.foo:
> return 1
> else:
> return 0
With __cmp__, in cases like that yo
On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > I'm actually currently in favor of keeping __cmp__ as it is in Python
> > 2.5. If a class defines only __cmp__, Python will do the appropriate
> > dance to make <, >, ==, etc. work right. If a class defines only
> > __eq__, __lt__, etc. Pytho
On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > > On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > cmp and __cmp__ are doomed, due to unorderable types now raising
>
On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > cmp and __cmp__ are doomed, due to unorderable types now raising
> > > exceptions:
> > >
> > > >>> cmp(3, 'hello')
> > > Tracebac
On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > cmp and __cmp__ are doomed, due to unorderable types now raising exceptions:
> >
> > >>> cmp(3, 'hello')
> > Traceback (most recent call last):
> > File "", line 1, in
> > TypeError: u
On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> cmp and __cmp__ are doomed, due to unorderable types now raising exceptions:
>
> >>> cmp(3, 'hello')
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: unorderable types: int() < str()
> >>> 3 == 'hello'
> False
>
> A mixi
On 10/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > It's clear to me that the opposition to removing __cmp__ comes down to
> > "make the common things easy and the rare things possible". Removing
> > __cmp__ means one of the common things
On 10/30/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> It's clear to me that the opposition to removing __cmp__ comes down to
> "make the common things easy and the rare things possible". Removing
> __cmp__ means one of the common things (total ordering) becomes hard.
I don't really think that's it
On 10/30/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > It'd be simpler still if we only had __cmp__ and __eq__. I just don't
> > understand the use cases where that's not sufficient.
> >
> > Hrm. I guess set's subset checking requires more relationships than
> > __cmp__ provid
Adam Olsen wrote:
> It'd be simpler still if we only had __cmp__ and __eq__. I just don't
> understand the use cases where that's not sufficient.
>
> Hrm. I guess set's subset checking requires more relationships than
> __cmp__ provides.
Also, you might want to give the comparison operators mea
On 10/29/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 10/29/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> > I think several postings have explained better than I have on why __cmp__
> > is still very valuable. (See below.)
> >
> > Guido van Rossum posted earlier that he was willing to e
On 10/29/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
> > It's not clear to me how many distinct operations you'd need though,
> > or how acceptable reflections would be.
>
> My intention was just to directly expose the tp_richcmp
> slot, so there would be six.
>
> To make things e
Adam Olsen wrote:
> It's not clear to me how many distinct operations you'd need though,
> or how acceptable reflections would be.
My intention was just to directly expose the tp_richcmp
slot, so there would be six.
To make things easier in the common case, there could
perhaps be a utility functi
2007/10/29, Greg Ewing <[EMAIL PROTECTED]>:
> David A. Wheeler wrote:
> > Greg Ewing stated "Why not provide a __richcmp__ method that
> > directly connects with the corresponding type slot?
>
> > It _seems_ to me that this is the same as "__cmp__",
>
> No, it's not -- a __richcmp__ method would ta
David A. Wheeler wrote:
> Greg Ewing stated "Why not provide a __richcmp__ method that directly connects
> with the corresponding type slot?
> It _seems_ to me that this is the same as "__cmp__",
No, it's not -- a __richcmp__ method would take an extra
argument specifying which of the six compari
I'm a bit too busy to look into this right now; I hope one or two more
rounds of feedback on the PEP will get it into a state where I can
review it more easily. Having a patch to go with it would be immensely
helpful as well (in fact I'd say that without a patch it's unlikely to
happen).
--Guido
On 10/29/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> I think several postings have explained better than I have on why __cmp__ is
> still very valuable. (See below.)
>
> Guido van Rossum posted earlier that he was willing to entertain a PEP to
> restore __cmp__, so I've attempted to create
On 10/29/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> I think several postings have explained better than I have on why __cmp__ is
> still very valuable. (See below.)
>
> Guido van Rossum posted earlier that he was willing to entertain a PEP to
> restore __cmp__, so I've attempted to create
I think several postings have explained better than I have on why __cmp__ is
still very valuable. (See below.)
Guido van Rossum posted earlier that he was willing to entertain a PEP to
restore __cmp__, so I've attempted to create a draft PEP, posted here:
http://www.dwheeler.com/misc/pep-cmp.
Steven Bethard wrote:
> I'm having troubles coming up with things where the *basic* operator
> is really a cmp-like function.
Think of things like comparing a tuple. You need to work your
way along and recursively compare the elements. The decision
about when to stop always involves ==, whatever c
David A. Wheeler wrote:
> But mixins for comparison are a BIG LOSER for sort performance
Why not provide a __richcmp__ method that directly connects
with the corresponding type slot? All the comparisons
eventually end up there anyway, so it seems like the
right place to provide a one-stop comparis
On 10/17/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I'm having troubles coming up with things where the *basic* operator
> is really a cmp-like function.
Here's one. When implementing the '<' operator on lists or tuples, you
really want to call the 'cmp' operator on the individual items,
beca
On Wed, Oct 17, 2007, Steven Bethard wrote:
>
> I'm having troubles coming up with things where the *basic* operator
> is really a cmp-like function. Even in your example, the cmp function
> was defined in terms of "less than". If the basic operator is really
> "less than", then why define a cmp()
On 10/17/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> I said:
> > I agree with Collin Winter: losing __cmp__ is a loss (see
> > http://oakwinter.com/code/).
>
> Steven Bethard said:
> >Why can't this just be supplied with a mixin? Here's a recipe
> >providing the appropriate mixins if you w
On 10/17/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> I said:
> > I agree with Collin Winter: losing __cmp__ is a loss (see
> > http://oakwinter.com/code/).
>
> Steven Bethard said:
> >Why can't this just be supplied with a mixin? Here's a recipe
> >providing the appropriate mixins if you w
On 10/17/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> class NumberMixinCmp(ComparisonMixin):
...
> def cmp(self, other):
> if self.x == other.x: return 0
> return (-1 if self.x < other.x else 1)
In the common case the == test will be false. About ~1/2 of the
tests will b
I said:
> I did a test (see below), and the mixin using a simulated cmp took
> 50% MORE time to sort a list using Python 2.5 (see code below) than
> when __cmp__ is used directly (as you CAN do in Python 2.5).
Oops, I forgot to post the actual numbers. Here they are, on my box (your
mileage will
I said:
> I agree with Collin Winter: losing __cmp__ is a loss (see
> http://oakwinter.com/code/).
Steven Bethard said:
>Why can't this just be supplied with a mixin? Here's a recipe
>providing the appropriate mixins if you want to define a __key__
>function:
>http://aspn.activestate.com/AS
On 10/16/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> I agree with Collin Winter: losing __cmp__ is a loss (see
> http://oakwinter.com/code/).
>
> Yes, it's possible to write all the comparison operations, but I think it's
> _clearer_ to create a single low-level operator that handles ALL t
On 10/16/07, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> I agree with Collin Winter: losing __cmp__ is a loss (see
> http://oakwinter.com/code/).
>
> Yes, it's possible to write all the comparison operations, but I think
> it's _clearer_ to create a single low-level operator that handles ALL
>
39 matches
Mail list logo
