[Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.
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