On 12/28/05, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Noam Raphael wrote:
> > I don't think that every type that supports equality
> > comparison should support order comparison. I think
> > that if there's no meaningful comparison (whether
> > equality or order), an exception should be raise
On 12/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote:
>
> Just to keep myself sane...
>
> def date_range(start=None, end=None):
> if start == None:
> start = datetime.date.today()
> if end == None:
> end = datetime.date.today()
> return end
Title: RE: [Python-Dev] Keep default comparisons - or add a second set?
Noam Raphael wrote:
> I don't think that every type that supports equality
> comparison should support order comparison. I think
> that if there's no meaningful comparison (whether
> equality o
On 12/28/05, Noam Raphael <[EMAIL PROTECTED]> wrote:
> On 12/28/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Speaking of id, there's no reason why "id(a) == id(b)" has to fail for
> > mismatched types in the face of persistence so long as the result of
> > id() has the same lifetime as the target
On 12/28/05, Adam Olsen <[EMAIL PROTECTED]> wrote:
> I agree for greaterthan and lessthan operators but I'm not convinced
> for equality. Consider this in contrast to your example:
> >>> a = 1+2j
> >>> b = 1+2j
> >>> a is b
> False
> >>> a == b
> True
>
> Complex numbers can't be sorted but they c
On 12/28/05, Noam Raphael <[EMAIL PROTECTED]> wrote:
> And another example:
>
> >>> a = 1+2j
> >>> b = 2+1j
> >>> a > b
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: no ordering relation is defined for complex numbers
>
> I came to think that, when forgetting backwards
On Wednesday, December 28, 2005 Noam Raphael wrote:
> I came to think that, when forgetting backwards compatibility for a
> while, the best thing for comparison operators to do is to raise a
> TypeError by default, and work only for types that it makes sense to
> compare. I think it is more "explic
And another example:
>>> a = 1+2j
>>> b = 2+1j
>>> a > b
Traceback (most recent call last):
File "", line 1, in
TypeError: no ordering relation is defined for complex numbers
I came to think that, when forgetting backwards compatibility for a
while, the best thing for comparison operators to d
On 12/27/05, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Tell me:
> >>> a = [0] * 3
> >>> b = [0] * 3
> >>> a[0] = b
> >>> b[0] = a
>
> What order should a and b have?
More gems:
>>> Decimal(3) < 4.0
False
>>> Decimal(3) == 3.0
False
>>> Decimal(3) > 4.0
True
And the pièce de résistance:
Jim Jewett wrote:
> Jim Fulton asked how this canonical ordering
> should be defined.
>
> The obvious answer is "Just like the __lt__
> operator today". But it doesn't actually *need*
> to be that sensible, if there are strong reasons
> to prefer a simpler ordering.
>
> The more I think about i
Today, x < y will return a consistent result,
even if the two objects are not comparable
in any meaningful manner.[*] The current plan
for Python 3 is to instead raise TypeError.
If this really needs to be changed (and I don't
think it does), then there should still be a s
Josiah Carlson wrote:
> Jim Fulton <[EMAIL PROTECTED]> wrote:
>> Jim Jewett wrote:
>>> PEP 3000 now suggests that dropping default comparison has become more
>>> than an idle what-if.
>>>
>>> Unfortunately, one very common use case of comparisons is to get a
>>> canonical order. If the order is se
Jim Fulton <[EMAIL PROTECTED]> wrote:
>
> Jim Jewett wrote:
> > PEP 3000 now suggests that dropping default comparison has become more
> > than an idle what-if.
> >
> > Unfortunately, one very common use case of comparisons is to get a
> > canonical order. If the order is sensible, all the bett
On 12/19/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Michael Urman <[EMAIL PROTECTED]> wrote:
> > Such as sorted(stuff, key=id)?
>
> I believe that ideally, canonical orderings would be persistant across
> sessions.
Erm, yes, I totally missed that in Jim's original preferred
requirements. An
Jim Jewett wrote:
> PEP 3000 now suggests that dropping default comparison has become more
> than an idle what-if.
>
> Unfortunately, one very common use case of comparisons is to get a
> canonical order. If the order is sensible, all the better, but that
> is not strictly required. One of Pytho
Michael Urman <[EMAIL PROTECTED]> wrote:
>
> On 12/19/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > That would be my preference. Comparison for canonical
> > ordering should be a distinct operation with its
> > own spelling.
>
> Such as sorted(stuff, key=id)?
I believe that ideally, canonical o
On 12/19/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> That would be my preference. Comparison for canonical
> ordering should be a distinct operation with its
> own spelling.
Such as sorted(stuff, key=id)?
Michael
--
Michael Urman http://www.tortall.net/mu/blog
___
Jim Jewett wrote:
> Or, at the very least, promote a
> *standard* way to say "just get me a canonical ordering of some sort"
That would be my preference. Comparison for canonical
ordering should be a distinct operation with its
own spelling. Then Guido's
> Comparisons other than == and !
On 12/19/05, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Unfortunately, one very common use case of comparisons is to get a
> canonical order. If the order is sensible, all the better, but that
> is not strictly required. One of Python's selling points (especially
> compared to Java) is that getting
PEP 3000 now suggests that dropping default comparison has become more
than an idle what-if.
Unfortunately, one very common use case of comparisons is to get a
canonical order. If the order is sensible, all the better, but that
is not strictly required. One of Python's selling points (especially
20 matches
Mail list logo
