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