[Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k. (original) (raw)

Glenn Linderman v+python at g.nevcal.com
Sat Mar 20 07:14:24 CET 2010

On 3/19/2010 9:20 PM, Nick Coghlan wrote:

Glenn Linderman wrote:

> The same person that would expect both > > 0 == "0" > 0.0 == "0.0" > > to be False... i.e. anyone that hasn't coded in Perl for too many years. Completely different - that is comparing numbers to strings.

One can argue that either way, that it is completely different, or completely the same. Is the map the territory, or is the territory the map? The human representation of the numbers in string form is meaningful numerically, and there are explicit conversions between them that prove that it is so.

But it is completely different, because Python doesn't do implicit coercion of strings to numbers, so they don't belong in the tree.

But it is completely the same, because Python doesn't do implicit coercion of Decimal to numbers, so they don't belong in the tree.

Completely different, because Python also doesn't do numeric operations on strings either... so the analogy only goes so far, admittedly. Even Perl, which will implicitly coerce string to numbers, has very limited numeric operations that are performed on the string form.

Thanks, though for the nice chart from an internals guy, you confirmed all that I thought I knew about how this presently works, from PEP and manual reading, a bit of experimentation, and the discussions here.

I have no problem with Guido's latest proposal in the rebooted thread, as long as there is a way to wall off the Decimal type from creeping errors due to implicit conversions and inaccurate types. It is presently an excellent feature of Python to have a way to be sure that conversions are explicit to retain proper accuracy. Few languages have that without requiring the user to write the whole class himself (or beg, borrow, or buy it). As he implicitly points out, while declaring that mixed arithmetic might be appropriate, that it either needs to be done correctly and completely, or not at all.

Glenn

More information about the Python-Dev mailing list