Decimal module performs wrong floor division with negative numbers

[regmeg]

BPO	42936
Nosy	@mdickinson, @regmeg

^{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 = None
closed_at = <Date 2021-01-15.16:26:05.305>
created_at = <Date 2021-01-15.15:33:47.899>
labels = ['invalid', '3.8']
title = 'Decimal module performs wrong floor division with negative numbers'
updated_at = <Date 2021-01-15.16:26:05.305>
user = 'https://github.com/regmeg'

bugs.python.org fields:

activity = <Date 2021-01-15.16:26:05.305>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2021-01-15.16:26:05.305>
closer = 'mark.dickinson'
components = []
creation = <Date 2021-01-15.15:33:47.899>
creator = 'multiks2200'
dependencies = []
files = []
hgrepos = []
issue_num = 42936
keywords = []
message_count = 3.0
messages = ['385113', '385114', '385117']
nosy_count = 2.0
nosy_names = ['mark.dickinson', 'multiks2200']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue42936'
versions = ['Python 3.8']

[regmeg]

from decimal import Decimal

print(-0.9//0.123)
# prints -8.0
print(Decimal('-0.9')//Decimal('0.123'))
# prints -7
print(-10//4.2)
# prints -3.0
print(Decimal('-10')//Decimal('4.2'))
# prints -2

[mdickinson]

The behaviour is deliberate, if unfortunate: it's covered in the documentation here: https://docs.python.org/3/library/decimal.html#decimal-objects - see the paragraph starting

There are some small differences between arithmetic on Decimal objects
and arithmetic on integers and floats. When the remainder operator % is
applied to Decimal objects

The issue is that the decimal spec specifies "divide-integer" and "remainder" operations. We've chosen to map those operations to "%" and "//" for convenience, even though there's a difference between float and Decimal here.

[mdickinson]

Thanks for the report. I'm going to close here, since this isn't a bug.

If you want to advocate for a behaviour change, by all means go ahead, but be aware that it would likely be a hard sell. The main challenge would be finding a way to change the behaviour that doesn't abruptly break existing code that depends on the current semantics.