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.
Mark
Mark
_______________________________________________
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
