Mark Dickinson <dicki...@gmail.com> wrote:
> > I like the simplicity of having a single signal (e.g. CoercionError), but
> > a strictness context flag could offer greater control for people who only
> > want pure decimal/integer operations.
>
> Sounds worth considering.
>
> > For example:
> >
> > strictness 0: completely promiscuous behaviour
> >
> > strictness 1: current py3k behaviour
> >
> > 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:
>>> from decimal import *
>>> DefaultContext.strictness = 1
>>> Decimal(9) == 9.0
False
>>> Decimal(9) in [1, 4.0 ,9]
True
>>> 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
>>> Decimal(9) in [1, 4.0 ,9]
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 4.0 to Decimal
>>> Decimal(9) in [1, 4 ,9]
True
This mode could help catch bugs like:
n = 7 / 3 # Programmer thinks this is an integer
x = Decimal(100)
while x != n:
pass # do something
x -= 1
> > strictness 3: current py3k behaviour + pure equality comparisons +
> > disallow NaN equality comparisons [1]
>
> Sorry, no. I think there are good reasons for the current NaN
> equality behaviour: 2.0 really *isn't* a NaN, and Decimal(2) ==
> Decimal('nan') should return False rather than raising an exception.
> And the decimal module provides compare and compare_signal for those
> who want complete standards-backed control here.
I'd like to make it an option for people who don't want to write:
while x.compare_signal(7) != 0
And I think that an sNaN should really signal by default.
> Besides, this seems
> to me to be an orthogonal issue to the issue of mixing Decimal with
> other numeric types.
Yes, it would kind of overload the strictness parameter. I see it as another
type of strictness, so I brought it up here. Level 3 would be a bit like
the highest warning level of a compiler.
But of course there's no need to discuss NaNs further in this thread other
than to show a possible use of the flag.
Stefan Krah
_______________________________________________
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
