[Python-ideas] Changing Decimal.__pos__ and Decimal.__neg__ [Was: Re: Python Numbers as Human Concept Decimal System]

[Oscar Benjamin]

On 10 March 2014 10:16, Oscar Benjamin <oscar.j.benjamin at gmail.com> wrote:
> On 10 March 2014 08:32, Mark Dickinson <dickinsm at gmail.com> wrote:
>> On Sun, Mar 9, 2014 at 8:07 PM, Oscar Benjamin <oscar.j.benjamin at gmail.com>
>> wrote:
>>>
>>> The problem though is with things like +3.14d or -3.14d. Python the
>>> language treats the + and - signs as not being part of the literal but
>>> as separate unary operators. This is unimportant for int, float and
>>> imaginary literals because there unary + is a no-op and unary - is
>>> exact. For decimal this is not the same as +Decimal('3.14') is not the
>>> same as Decimal('+3.14'):
>>
>> Another option would be to change the behaviour of + and - on Decimal
>> objects by binding `__pos__` and `__neg__` to the specification's 'copy' and
>> 'copy-negate' operations instead of (as currently) to the 'plus' and 'minus'
>> operations.  Those behaviours are more in keeping with the way that + and -
>> operate on other objects.
>
> Hi Mark and thanks for responding,
>
> Do you think it's really feasible to make such a change? The use of
> unary + for rounding to context has been a feature of the decimal
> module for as long as I've been using it. It's shown in the docs both
> in the Recipes section and the FAQ.

On the other hand the issue is primarily with __neg__ rather than
__pos__as I see it because a leading + is unnecessary and I really
just want a safe way of spelling a negative value. I can't see any
documented reference to the behaviour of Decimal.__neg__ and it's
probably used less often with the same intent.

So perhaps only __neg__ could be changed. This would still be a
backward-incompatible change but I think it would have significantly
less breakage.


Oscar