On Wed, Mar 17, 2010 at 8:04 AM, Mark Dickinson <dicki...@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 5:15 PM, Guido van Rossum <gu...@python.org> wrote:
>> Definitely some. Stricter comparison rules are a frequent cause of
>> problems when code is first ported to 3.x. While you'd think that code
>> comparing a float and a Decimal is *already* broken, there's a
>> surprising number of situations where that's not necessary the case,
>> e.g. when an arbitrary but stable ordering is needed.
>
> Hmm. Okay. It seems like backporting the exception isn't a real option,
> then.
>
> A nitpick: the current 2.x behaviour fails to give an arbitrary but
> stable ordering; it merely gives an arbitrary ordering:
>
>>>> sorted([Decimal(1), 2, 3.0])
> [Decimal('1'), 2, 3.0]
>>>> sorted([2, Decimal(1), 3.0])
> [3.0, Decimal('1'), 2]
>
> So long as your list contains only floats and Decimals you're fine,
> but for a list containing floats, integers and Decimals the ordering
> is no longer stable: the problem, of course, being that int <-> float
> and int <-> Decimal comparisons use a rule (compare by numeric value)
> that's not compatible with the way that floats and Decimals are
> compared. This seems like yet another possible cause of subtle bugs,
> and again would be fixed by the proposed change in behaviour. On the
> other hand, I've not seen any reports of anyone encountering this in
> real life.
Ok, I'll try to stay out of the discussion of which solution is best
of our users, and if the outcome is that mixed operations in general
are bad but mixed comparisons are good, I'll trust you. However I want
to reiterate that you really shouldn't improve the situation for 2.7
unless you also forward-port the solution to 3.x.
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
