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.

Author tim.peters
Recipients mark.dickinson, python-dev, rhettinger, serhiy.storchaka, tim.peters, vstinner
Date 2016-01-27.18:56:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1453920965.54.0.103658001421.issue26194@psf.upfronthosting.co.za>
In-reply-to
Content
I'd raise an exception when trying to insert into a bounded deque that's already full.  There's simply no way to guess what was _intended_; it's dead easy for the user to implement what they _do_ intend (first make room by deleting the specific item they no longer want); and I can't think of a use case compelling enough to justify whatever arbitrary non-exceptional behavior may be implemented instead.

WRT the behavior you settled on, sure, it's explainable.  That doesn't imply it's useful, though ;-)  I'd rather have an exception.  It's plain bizarre that after

    d.insert(i, x)

one can't even rely on

    assert any(y is x for y in d)

succeeding.  Implementing behavior that allows that invariant to fail is _really_ user-unfriendly ;-)

In contrast, what .append() and .appendleft() do for a full bounded deque are compelling (and don't violate the weak invariant above).
History
Date User Action Args
2016-01-27 18:56:05tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, vstinner, python-dev, serhiy.storchaka
2016-01-27 18:56:05tim.peterssetmessageid: <1453920965.54.0.103658001421.issue26194@psf.upfronthosting.co.za>
2016-01-27 18:56:05tim.peterslinkissue26194 messages
2016-01-27 18:56:05tim.peterscreate