decimal.py: minor issues && usability

[skrah]

BPO	6795
Nosy	@rhettinger, @facundobatista, @mdickinson, @skrah

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/mdickinson'
closed_at = <Date 2009-09-08.19:24:42.365>
created_at = <Date 2009-08-28.10:28:26.472>
labels = ['type-bug', 'library']
title = 'decimal.py: minor issues && usability'
updated_at = <Date 2009-09-08.19:24:42.346>
user = 'https://github.com/skrah'

bugs.python.org fields:

activity = <Date 2009-09-08.19:24:42.346>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2009-09-08.19:24:42.365>
closer = 'mark.dickinson'
components = ['Library (Lib)']
creation = <Date 2009-08-28.10:28:26.472>
creator = 'skrah'
dependencies = []
files = []
hgrepos = []
issue_num = 6795
keywords = []
message_count = 7.0
messages = ['92034', '92039', '92262', '92368', '92380', '92381', '92426']
nosy_count = 4.0
nosy_names = ['rhettinger', 'facundobatista', 'mark.dickinson', 'skrah']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue6795'
versions = ['Python 2.6', 'Python 3.1', 'Python 2.7', 'Python 3.2']

[skrah]

Hi,

a couple of minor issues:

1:
>>> c = getcontext()
>>> c.traps[InvalidOperation] = False
>>> Decimal("NaN").__int__()
Decimal('NaN')

I think the return value should be None.

2:
>>> c = getcontext()
>>> c.traps[InvalidOperation] = False
>>> Decimal("NaN").__long__()
Traceback (most recent call last):
...
RuntimeError: maximum recursion depth exceeded in cmp


3:
>>> setcontext(8)
>>> getcontext()
8

This is just a usability issue, perhaps a type check could be performed.

[mdickinson]

Thanks for the reports.

Issue 1. If this is going to be changed, I'd rather see
int(Decimal('nan')) raise ValueError (just as int(float('nan')) does)
than return None.

Conversions from Decimal to native integers lie outside the scope of the
standard, so there's not much help there. However, precisely *because*
they lie outside the standard, it seems wrong to be raising a Decimal
exception (Decimal.InvalidContext) here. It's also inconsistent with
the treatment of infinities: int(Decimal('infinity')) currently gives
an OverflowError.

Given the lack of guidance from the decimal standard, the next place to
turn is probably IEEE 754. IEEE 754-2008, section 5.8 ("Details of
conversions from floating-point to integer formats") says:

"""When a NaN or infinite operand cannot be represented in the
destination format and this cannot otherwise be indicated, the invalid
operation exception shall be signaled."""

As far as I can tell, when the invalid-operation trap is disabled, the
return value is undefined in this case (see 7.2(i) in IEEE 754-2008).

But in Python this error condition *can* 'otherwise be indicated', by
raising a suitable Python exception. So I propose changing the decimal
module in 2.7 and 3.2 so that int(Decimal('nan')) and
long(Decimal('nan')) raise ValueError.

Raymond, Facundo: any thoughts on this?

Issue 2. A clear bug; will fix. Thanks.

Issue 3. I can't see how this could cause any real problems, since you'd
get an error as soon as you tried to use a bogus context. Further, an
explicit typecheck goes against Python's duck-typing philosophy: a
suitably crazy and misguided person ought to be able to create their own
'quacks like a context' class, not necessarily inheriting from
Decimal.Context, and pass this into setcontext in place of a real
context. I'm -0 on changing this.

[facundobatista]

Issue 1: +1 to raise ValueError

Issue 3: -0 to change actual behaviour

Thanks!

[skrah]

[...]

But in Python this error condition *can* 'otherwise be indicated', by
raising a suitable Python exception. So I propose changing the decimal
module in 2.7 and 3.2 so that int(Decimal('nan')) and
long(Decimal('nan')) raise ValueError.

Excellent analysis, I would be very much in favour of this.

Issue 3. I can't see how this could cause any real problems, since you'd
get an error as soon as you tried to use a bogus context. Further, an
explicit typecheck goes against Python's duck-typing philosophy: a
suitably crazy and misguided person ought to be able to create their own
'quacks like a context' class, not necessarily inheriting from
Decimal.Context, and pass this into setcontext in place of a real
context. I'm -0 on changing this.

Agreed, it's not really important.

[mdickinson]

Fixed __long__ bug and changed behaviour of int(Decimal('nan')) in r74708
(trunk), r74709 (py3k). I still need to fix the __long__ bug in the
release branches.

[mdickinson]

On second thoughts, I'm going to call this a bug and backport to 2.6 and
3.1.

[mdickinson]

Fixed in r74719 (release26-maint), r74720 (release31-maint).