On Tue, Mar 23, 2010 at 3:09 PM, Stefan Krah <ste...@bytereef.org> wrote:
> Mark Dickinson <dicki...@gmail.com> wrote:
>> [Stefan]
>> >
>> > strictness 2: current py3k behaviour + pure equality comparisons
>>
>> Can you explain what you mean by "+ pure equality comparisons" here?
>> If I'm understanding correctly, this is a mode that's *more* strict
>> than the current py3k behaviour; what's it disallowing that the
>> current py3k behaviour allows?
>
> It's disallowing all comparisons between e.g. float and decimal. The idea
> is that the context can provide a cheap way of enforcing types for people
> who like it:
>>>> DefaultContext.strictness = 2
>>>> Decimal(9) == 9.0
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/home/stefan/svn/py3k/Lib/decimal.py", line 858, in __eq__
> other = _convert_other(other)
> File "/home/stefan/svn/py3k/Lib/decimal.py", line 5791, in _convert_other
> raise TypeError("Unable to convert %s to Decimal" % other)
> TypeError: Unable to convert 9.0 to Decimal
Hmm. It seems to me that deliberately making an __eq__ method between
hashable types raise an exception isn't something that should be done
lightly, since it can *really* screw up sets and dicts. For example,
with your proposal, {9.0, Decimal(x)} would either raise or not,
depending on whether Decimal(x) happened to hash equal to 9.0 (if they
don't hash equal, then __eq__ will never be called). If the hash is
regarded as essentially a black box (which is what it should be for
most users) then you can easily end up with code that almost always
works, but *very* occasionally and unpredicatably raises an exception.
> And I think that an sNaN should really signal by default.
Agreed, notwithstanding the above comments. Though to avoid the
problems described above, I think the only way to make this acceptable
would be to prevent hashing of signaling nans. (Which the decimal
module current does; it also prevents hashing of quiet NaNs, but I
can't see any good rationale for that.)
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
