[Python-Dev] Decimal <-> float comparisons in py3k. (original) (raw)
Glenn Linderman glenn at nevcal.com
Fri Mar 19 03:08:56 CET 2010
- Previous message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Next message: [Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/18/2010 6:18 PM, Antoine Pitrou wrote:
Glenn Linderman<v+python g.nevcal.com> writes:
On 3/18/2010 2:48 PM, Nick Coghlan wrote:
When there is a clear, correct way (based on Decimal.fromfloat) to make numeric comparison behave in accordance with the rules of mathematics, do we really want to preserve strange, unintuitive behaviour like the above? I'm aware of nothing that prevents the lazy coder from having a class unifiedNumber in his toolbox [snip] Please stick to the topic. We are talking about Python's default behaviour here.
Yes, I consider my comment relevant, and think that you should apologize for claiming it is off topic.
There are two choices on the table -- doing comparisons implicitly between Decimal and float, and raising an exception. It seems the current behavior, sorting by type, is universally disliked, but doing nothing is a third choice.
So if the default behavior is to raise an exception, my comment pointed
out the way comparisons could be provided, for those that need them.
This allows both behaviors to exist concurrently. Python developers
could even consider including such a library in the standard library,
although my suggestion didn't include that.
On the other hand, if the default behavior is to do an implicit conversion, I don't know of any way that that could be turned into an exception for those coders that don't want or don't like the particular type of implicit conversion chosen.
Glenn
- Previous message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Next message: [Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]