Daniel Stutzbach wrote:
> I apologize if this is a silly question, but what would be the
> difference between the proposed __richcmp__ and the old __cmp__ that's
> being removed?
__richcmp__ would have the same signature as the C-level
tp_richcmp slot, i.e. taking a code indicating which
comparis
Terry Reedy schrieb:
| > In any case, this point is that dict ordering is as arbitrary as
ordering,
| > for instance, a dict and a string. Since Guido stopped the experiment
of
| > totally ordering all objects when complex nums were added, consistency
| > suggests that all fake orderings be el
On 3/21/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> In addition to this, what about the idea of a Python-level
> __richcmp__ method? It would provide a single point of override
> for classes that wanted to use it, and it shouldn't upset any
> default behaviours since it's just exposing what's there
Adam Olsen wrote:
> On 3/20/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
>
> > I've used a __key__() method quite successfully in my own code. Maybe
> > we should provide a mixin like::
>
> This seems to match what I've usually needed, but I'm not sure it's
> worth putting in python proper.
In
On 3/21/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Terry Reedy schrieb:
> > "Georg Brandl" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > | Yes, but dictionaries had an explicit ordering in dict_compare() which
> > was
> > | deleted.
> >
> > Is dict_compare something added i
Terry Reedy schrieb:
> "Georg Brandl" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | Yes, but dictionaries had an explicit ordering in dict_compare() which
> was
> | deleted.
>
> Is dict_compare something added in 2.5? It is neither a builtin or dict
> method in 2.4.
No, it
On 3/21/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 3/21/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 3/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > [snip]
> > > Or we could just have 2.6 warn about the presence (or use) of __cmp__
> > > -- users can write equivalent code us
On 3/21/07, Collin Winter <[EMAIL PROTECTED]> wrote:
On 3/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[snip]
> Or we could just have 2.6 warn about the presence (or use) of __cmp__
> -- users can write equivalent code using __lt__ etc. themselves and
> probably do a better job.
Fair enou
On 3/21/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > I've used a __key__() method quite successfully in my own code. Maybe
> > we should provide a mixin like::
> >
> > class KeyedComparisonMixin(object):
> > def __eq__(self, othe
On 3/21/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [snip]
> > Or we could just have 2.6 warn about the presence (or use) of __cmp__
> > -- users can write equivalent code using __lt__ etc. themselves and
> > probably do a better job.
>
>
On 3/20/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Quoting from the commit message for r51533, which removed the default
> > ordering:
> >
> > """
> > A general problem with getting lots of these tests to pass is
> > the reality that fo
On 3/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[snip]
> Or we could just have 2.6 warn about the presence (or use) of __cmp__
> -- users can write equivalent code using __lt__ etc. themselves and
> probably do a better job.
Fair enough.
Is anyone collecting a list of these --py3k warning
"Georg Brandl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Yes, but dictionaries had an explicit ordering in dict_compare() which
was
| deleted.
Is dict_compare something added in 2.5? It is neither a builtin or dict
method in 2.4.
In any case, this point is that dict order
On 3/21/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> BTW, was it intentional that dicts can't be compared via ">" and "<"
> anymore?
Yes. In old Python it made sense since all objects were supposed to be
orderable *somehow* (in the truly distant past, comparisons weren't
even allowed to raise exc
Josiah Carlson schrieb:
> Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum schrieb:
>> > I haven't taken any action, and it looks like __cmp__ isn't being
>> > called. I'd rather not add it back; if you want it back, could you at
>> > least write up a brief PEP? A patch would also help;
Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > I haven't taken any action, and it looks like __cmp__ isn't being
> > called. I'd rather not add it back; if you want it back, could you at
> > least write up a brief PEP? A patch would also help; I recall that it
> > was quit
Guido van Rossum schrieb:
> I haven't taken any action, and it looks like __cmp__ isn't being
> called. I'd rather not add it back; if you want it back, could you at
> least write up a brief PEP? A patch would also help; I recall that it
> was quite a relief being able to cut it out, so I expect th
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| But can this work? It might end up calling cmp() on two incomparable
| objects. For __lt__ etc. that might be the right answer, but for
| __eq__ it is *not* -- the default __eq__ and __ne__ *must* compare
| object id
On 3/20/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I've used a __key__() method quite successfully in my own code. Maybe
> we should provide a mixin like::
>
> class KeyedComparisonMixin(object):
> def __eq__(self, other):
> return self.__key__() == other.__key__()
[sn
On 3/20/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I haven't taken any action, and it looks like __cmp__ isn't being
> > called. I'd rather not add it back; if you want it back, could you at
> > least write up a brief PEP? A patch woul
On 3/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I haven't taken any action, and it looks like __cmp__ isn't being
> called. I'd rather not add it back; if you want it back, could you at
> least write up a brief PEP? A patch would also help; I recall that it
> was quite a relief being able
How would that produce the desired behavior that == and != are defined
on all objects, but <, <=, >= and > are not? We're quickly approaching
python-ideas land... :)
On 3/20/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Quoting from the co
On 3/20/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Quoting from the commit message for r51533, which removed the default
> ordering:
>
> """
> A general problem with getting lots of these tests to pass is
> the reality that for object types that have a natural total ordering,
> implementing __
But can this work? It might end up calling cmp() on two incomparable
objects. For __lt__ etc. that might be the right answer, but for
__eq__ it is *not* -- the default __eq__ and __ne__ *must* compare
object identity.
(What is this __cmp you refer to? A typo for __cmp__ or for cmp?)
--Guido
On 3
"Collin Winter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Quoting from the commit message for r51533, which removed the default
ordering:
|
| What's the status on this? FWIW, I would like to see __cmp__ stay as a
| fallback measure if __eq__, __ne__, __lt__, etc aren't define
I haven't taken any action, and it looks like __cmp__ isn't being
called. I'd rather not add it back; if you want it back, could you at
least write up a brief PEP? A patch would also help; I recall that it
was quite a relief being able to cut it out, so I expect that patching
it back in would be qu
26 matches
Mail list logo
