[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