msg183918 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2013-03-11 03:20 |
Once added, use it in threading.Condition(). |
|
|
msg190873 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2013-06-09 20:34 |
The slicing support can be implemented using just rotates, appends, and pops. |
|
|
msg197578 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2013-09-13 14:15 |
What type should be a result of slicing? List, tuple, deque, other? |
|
|
msg243029 - (view) |
Author: Larry Hastings (larry) *  |
Date: 2015-05-13 01:01 |
For the record, Raymond asked for permission to check this in (a new feature) for 3.5 beta 2, as he won't have time to finish it before beta 1. As 3.5 release manager I've given him permission. Go Raymond! |
|
|
msg257460 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2016-01-04 11:56 |
Proposed patch implements getting, deleting and setting slices in deque. Getting a slice returns a list, but this can be changed if needed. |
|
|
msg258997 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2016-01-27 07:42 |
Synchronized with current sources and added mandatory now braces. |
|
|
msg259001 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2016-01-27 08:31 |
Thank you for doing this work. |
|
|
msg259070 - (view) |
Author: Josh Rosenberg (josh.r) *  |
Date: 2016-01-27 22:56 |
It seems odd to have a slice of a deque return a list. Are there any other examples of non-buffer protocol objects behaving like this in the standard library/built-ins? Only examples I can come up with are mmap objects and ctypes arrays (which are making raw binary data available in Python); it seems rather surprising that a Python level type like deque would slice to produce a list. |
|
|
msg259089 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2016-01-28 04:04 |
Returning a deque is preferred. For this stage, I just want to review the code and make sure it algorithmically correct (slicing is complicated and has a lot of cases). |
|
|
msg259810 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2016-02-07 23:33 |
Since the patch is so complex, I suggest to split it on parts, and review and commit them separately: 1) Refactoring. Extract common code to macros and utility functions. These macros can be used for more efficient implementing insert() and __del__. 2) Add slice getting. 3) Add slice assignment and deleting. I'm not sure that this is needed for deque. |
|
|
msg259812 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2016-02-08 01:23 |
I'm already underway for the review. The "refactoring" part is making is more difficult. We just need slicing support to be added. Yes, I do want slice assignment and deletion. The output should be a deque, not a list. |
|
|
msg261285 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2016-03-07 08:04 |
The output now is a deque. |
|
|
msg267777 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2016-06-08 04:44 |
Raymond, do you have a time to make a review? |
|
|
msg272766 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2016-08-15 15:01 |
Raymond, do you still have an interest in this issue? If no, you can just close it. |
|
|
msg275180 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2016-09-08 21:50 |
Ping. |
|
|
msg275505 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2016-09-10 00:07 |
> If no, you can just close it. Yes, I would rather close this than apply this patch. |
|
|