This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Support __add__, __mul__, and __imul__ for deques.
Type: enhancement Stage: patch review
Components: Extension Modules Versions: Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: josh.r, python-dev, rhettinger
Priority: normal Keywords: needs review

Created on 2015-03-27 17:33 by rhettinger, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
deque_add4.diff rhettinger, 2015-03-27 17:33 Patch with tests review
deque_add5.diff rhettinger, 2015-03-27 18:33 Restrict addition to objects of the same type review
deque_mul_and_add.diff rhettinger, 2015-03-30 03:13 __add__, __mul__, and __imul__ review
Messages (8)
msg239419 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2015-03-27 17:33
One more step towards making the deque API a little closer to that for lists:
  
    >>> deque('abc') + deque('def')
    deque(['a', 'b', 'c', 'd', 'e', 'f'])
msg239563 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2015-03-30 03:13
Also incorporate __mul__ and __imul__.

    >>> d = deque('abc')
    >>> d * 3
    deque(['a', 'b', 'c', 'a', 'b', 'c', 'a', 'b', 'c'])
    >>> d *= 2
    >>> d
    deque(['a', 'b', 'c', 'a', 'b', 'c'])
msg239642 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2015-03-30 21:18
The behavior for multiplying or adding doesn't seem quite so intuitive when you allow for a bounded deque. In particular, it doesn't seem obvious that multiplying when the deque is bounded, you'll get results like:

>>> list(deque([1,2], 3) * 2)
[2, 1, 2]

Similarly, when you support non-in-place addition, the bounded-ness of the result depends on the order of the values added.

>>> list(deque([1,2], 3) + deque([1,2], 2))
[1, 2, 1]
>>> list(deque([1,2], 2) + deque([1,2], 3))
[1, 2]

Not saying these are the wrong behaviors, but it's much more weird than what you get with other sequence types (since most sequence types aren't bounded), and possibly why deques didn't include these features in the first place; trying to act like a generalized sequence when you have features that don't fit the model is a titch odd.
msg239646 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2015-03-30 22:23
I think my first addition example is wrong (should produce [2, 1, 2]), but you get the idea.
msg239652 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2015-03-31 01:38
> The behavior for multiplying or adding doesn't seem quite so 
> intuitive when you allow for a bounded deque.

What would you want it to do?  By design, the key feature of maxlen is pop old inputs to make way newer appends -- that is its essence.

It would be surprising if the following invariant didn't hold:

>>> deque('abc' * 3, maxlen=5) == deque('abc', maxlen=5) * 3
True

That said, I don't expect that people are going to commonly be doing d*=n where len(d) > 1 and there is a maxlen > len(d)*n.   The normal cases are unsurprising.
msg239682 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2015-03-31 10:39
I agree that popping old inputs is the normal way. What I'm trying to say is that it doesn't feel like "old" or "inputs" when you multiply. In that case (and maybe this is just me), it feels like a "reasonable" outcome could be to get an outcome similar to multiplying a list and then slicing the result to maxlen. I don't think it *should* do that, but either behavior feels weird, solely because sequence multiplication has never been applied to a bounded sequence before (to my knowledge), so the expectations aren't set.

You end up with weird behaviors like len(seq) * 3 != len(seq * 3), which is a normal and expected outcome with every other sequence. If you know you're dealing with a bounded deque, it's less unexpected, but this is trying to make a deque a drop-in replacement for any other sequence when it doesn't behave like one.
msg239722 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2015-03-31 15:01
I don't see any technical reason not to proceed.  Just because an unusual combination of parameters feels odd to you doesn't make it wrong.  It is no different than (somelist * n)[-maxlen:].
msg239724 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-03-31 15:13
New changeset b75160d24b7b by Raymond Hettinger in branch 'default':
Issue 23793:  Add deque support for __add__(), __mul__(), and __imul__().
https://hg.python.org/cpython/rev/b75160d24b7b
History
Date User Action Args
2022-04-11 14:58:14adminsetgithub: 67981
2015-03-31 15:14:17rhettingersetstatus: open -> closed
resolution: fixed
2015-03-31 15:13:30python-devsetnosy: + python-dev
messages: + msg239724
2015-03-31 15:01:39rhettingersetmessages: + msg239722
2015-03-31 10:39:07josh.rsetmessages: + msg239682
2015-03-31 01:38:01rhettingersetmessages: + msg239652
2015-03-30 22:23:40josh.rsetmessages: + msg239646
2015-03-30 21:18:24josh.rsetnosy: + josh.r
messages: + msg239642
2015-03-30 03:13:13rhettingersetkeywords: + needs review, - patch
files: + deque_mul_and_add.diff
messages: + msg239563

title: Support __add__ for deques. -> Support __add__, __mul__, and __imul__ for deques.
2015-03-27 18:33:58rhettingersetfiles: + deque_add5.diff
2015-03-27 17:33:58rhettingercreate