Re: Python list insert iterators

_list = LinkedList() for i in range(1, 11): linked_list.append(i) a = linked_list.index(1) print(a.value) b = linked_list.index(5) print(b.value) a.insert_after(27) b.insert_after(45) print(','.join(str(x) for x in linked_list)) unit_test() python_mailing

Re: Python list insert iterators

Guenther Sohler writes: Hi Python community, I have a got an example list like 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 T T and i eventually want to insert items in the given locations (A shall go between 2 and 3, B shall go between 6 and 7) Right now i just use

Re: Python list insert iterators

(a position relative to the beginning/end). No, it's not an option to sort the indexes and start inserting from the back. Without explaining this criteria (and any others), suggestions can only be guesses! The most elegant option is not to store indexes, but list iterators, which attach

RE: Python list insert iterators

bject: Re: Python list insert iterators On 3/3/2023 3:22 AM, Guenther Sohler wrote: > Hi Python community, > > I have a got an example list like > > 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 > T T > > and i eventually want to insert items in the given loca

Re: Python list insert iterators

. The most elegant option is not to store indexes, but list iterators, which attach to the list element and would automatically move, especially if an element is inserted before. I could not find such functionality in python lists of [ 1,2,3 ] Does python have such functionality ? if yes, where

Python list insert iterators

indexes, but list iterators, which attach to the list element and would automatically move, especially if an element is inserted before. I could not find such functionality in python lists of [ 1,2,3 ] Does python have such functionality ? if yes, where can i find it ? -- https://mail.python.org

[issue533281] bsddb185 module needs iterators

Change by admin : -- github: None -> 36307 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue463738] file object iterators

Change by admin : -- github: None -> 35224 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue449085] Exception iterators

Change by admin : -- github: None -> 34922 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue448153] Dictionary iterators break old code

Change by admin : -- github: None -> 34896 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Change by Alex : -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue31155] Encode set, frozenset, bytearray, and iterators as json arrays

Change by sedrubal : -- nosy: +sedrubal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

miss-islington added the comment: New changeset b500bd8e672d15c6dfa24568a3264fdc0f3e0c01 by Miss Islington (bot) in branch '3.9': bpo-43399: Fix ElementTree.extend not working on iterators (GH-24751) https://github.com/python/cpython/commit/b500bd8e672d15c6dfa24568a3264fdc0f3e0c01

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

miss-islington added the comment: New changeset c1079cde2a7676892a9b98703903206b7d26ed1f by Miss Islington (bot) in branch '3.8': bpo-43399: Fix ElementTree.extend not working on iterators (GH-24751) https://github.com/python/cpython/commit/c1079cde2a7676892a9b98703903206b7d26ed1f

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Serhiy Storchaka added the comment: Pinging us was the only action needed. Thank you for your contribution Alex. -- ___ Python tracker ___

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Change by miss-islington : -- pull_requests: +23847 pull_request: https://github.com/python/cpython/pull/25102 ___ Python tracker ___

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Change by miss-islington : -- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +23846 pull_request: https://github.com/python/cpython/pull/25101 ___ Python tracker

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Serhiy Storchaka added the comment: New changeset 51a85ddce8b336addcb61b96f04c9c5edef07296 by Alex Prengère in branch 'master': bpo-43399: Fix ElementTree.extend not working on iterators (GH-24751) https://github.com/python/cpython/commit/51a85ddce8b336addcb61b96f04c9c5edef07296

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Alex added the comment: Is there anything else I should be doing, in order to get this merged in time for 3.10? (the PR is "awaiting merge") For the record, the equivalent PR for PyPy is now merged in the py3.7 branch: https://foss.heptapod.net/pypy/pypy/-/merge_requests/807. Regarding the

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Change by Raymond Hettinger : -- nosy: +lukasz.langa ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Raymond Hettinger added the comment: +1 for back porting, but check with the RM first. -- nosy: +rhettinger ___ Python tracker ___

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Stefan Behnel added the comment: Thanks for the report and the PR. I would argue that this can still be fixed in Py3.8, given the low impact (but not earlier). The behaviour is clearly wrong (in a subtle way) and most users won't notice it because they won't switch off the C accelerator

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Serhiy Storchaka added the comment: Your proposed fix LGTM. Please open a PR. Don't forget about test and NEWS entry. -- ___ Python tracker ___

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Change by Karthikeyan Singaravelan : -- nosy: +eli.bendersky, scoder, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

Change by Alex : -- keywords: +patch pull_requests: +23521 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24751 ___ Python tracker ___

[issue43399] xml.etree.ElementTree.extend does not work with iterators when using the Python implementation

es: 388099 nosy: alexprengere priority: normal severity: normal status: open title: xml.etree.ElementTree.extend does not work with iterators when using the Python implementation type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 __

Pieshell: Combination of the expressiveness of shell pipelines and the power of python iterators

Hi! I've written a python package that lets you combine python code and shell pipelines: Pieshell is a Python shell environment that combines the expressiveness of shell pipelines with the prower of python iterators. It can be used in two major ways: As an interactive shell replacing e.g

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Vinay Sajip added the comment: Thanks for the PR. I reviewed it and requested changes about 3 weeks ago - you should have received a notification from GitHub when that happened. -- ___ Python tracker

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Brett Hannigan added the comment: Just wanted to check-in to see if there were any updates on my proposed PR? -- ___ Python tracker ___

Re: Iterators, iterables and special objects

On 25/07/2020 06:35, Random832 wrote: On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote: The transformers should be once-through iterators because they can be passed once-through interators. I suppose one could make them iterables and add an attribute 'pristine' set to True in __init__

Re: Iterators, iterables and special objects

, then build it - it isn't hard. Asking to be able to restart the iteration is hardly the same thing as asking to pass through subscripts etc... C#'s Linq functions do fine with restartable iterables and hardly ever expose Iterators [well, IEnumerators, as they're called] to the user at all. If the ori

Re: Iterators, iterables and special objects

On Thu, Jul 23, 2020, at 05:14, Peter Slížik wrote: > > Works in what way? You can't use it in a 'for' loop if it doesn't > > define __iter__. > > > > class Iterable: > def __iter__(self): > return Iterator(...) > > class Iterator: > def __next__(self): > return > >

Re: Iterators, iterables and special objects

On Sat, Jul 25, 2020 at 4:37 AM Random832 wrote: > > On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote: > > The transformers should be once-through iterators because they can be > > passed once-through interators. I suppose one could make them iterables > > and add an

Re: Iterators, iterables and special objects

On Tue, Jul 21, 2020, at 15:54, Terry Reedy wrote: > The transformers should be once-through iterators because they can be > passed once-through interators. I suppose one could make them iterables > and add an attribute 'pristine' set to True in __init__ and False in > __iter__, bu

Re: Iterators, iterables and special objects

(iterator) returns iterator. Open files are *iterators*. >>> file.__iter__() is file True This means that one can do things like file = open(...) for line in file: # Section 1 of file. if separator(line): break process1(line) process_sep(line) # Special line that broke iteration.

Re: Iterators, iterables and special objects

> Works in what way? You can't use it in a 'for' loop if it doesn't > define __iter__. > class Iterable: def __iter__(self): return Iterator(...) class Iterator: def __next__(self): return # No __iter__ here. # I've just forgotten to def it. With this setup,

Re: Iterators, iterables and special objects

On Thu, Jul 23, 2020 at 5:55 PM Peter Slížik wrote: > Moreover, some tutorial authors make it even more difficult with using the > terms iterator and iterable interchangeably. A notorious example is this > wiki: > https://wiki.python.org/moin/Iterator > > It says: > > *Here is an *iterator* that

Re: Iterators, iterables and special objects

> > class RandomIterable:def __iter__(self):return self Yes? It is indeed an iterator, since its iter method returns itself. It is also iterable, since it has an iter method. The article goes on to explain this. I don't think they're being used interchangeably here. >

Re: Iterators, iterables and special objects

> The view are iterables. They can be iterated more than once and used in > other operations. > > The transformers should be once-through iterators because they can be > passed once-through interators. This is important, thank you for pointing it out. > Python's design

Re: Iterators, iterables and special objects

shion or JiT (Just-in-time) delivery. Similarly, once a generator is "exhausted", it terminates. It cannot be re-used, without being re-computed. For your reading pleasure: PEP 3106 -- Revamping dict.keys(), .values() and .items() https://www.python.org/dev/peps/pep-3106/ 2. Why do th

Re: Iterators, iterables and special objects

on would just make execution slower and hide the specific info as to what the iterator is doing. 2. Why do these functions return iterators instead of iterables? The view are iterables. They can be iterated more than once and used in other operations. The transformers should be once-through

Iterators, iterables and special objects

do these functions return iterators instead of iterables? First, I find it confusing - to me, it is the loop's job to create an iterator from the supplied iterable, and not the object that is being iterated over. And second, with this design, iterators are required to be iterables too, which is

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Brett Hannigan added the comment: O.K. CLA is now signed and if I check on the "check-yourself" with my github user it is showing that I have signed it now. -- ___ Python tracker

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Brett Hannigan added the comment: Thanks. I don't know why it still says CLA not signed - I signed it a week ago, but I'll try to figure that out this week. -- ___ Python tracker

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Vinay Sajip added the comment: OK, seems like a reasonable use case. I haven't looked at the PR yet, as it still has a "CLA not signed" label, and I normally wait until the CLA is signed before looking more closely at PRs. -- ___ Python tracker

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Brett Hannigan added the comment: I encountered the need for the iterators when trying to create a subclass of the QueueHandler class that would manage both the QueueHandler and the QueueListener. The implementation is very similar to that described in this Medium post: https://medium.com

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Vinay Sajip added the comment: > If it is not goal I don't have a goal to make these part of a documented API. OP, can you share a use case where you need to iterate over these internal structures? -- ___ Python tracker

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Serhiy Storchaka added the comment: If you are going to make them public general purpose classes you need to implement also support of slices, __reversed__(), index(), remove(), count(), sort(), copy() in ConvertingList and more methods in ConvertingTuple, and ConvertingDict. If it is not

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Vinay Sajip added the comment: > I think the other issue here is that the ConvertingX classes aren't > documented apart from comments in the code where they are defined. That's deliberate - they're considered an internal implementation detail. --

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Michael DePalatis added the comment: I think the other issue here is that the ConvertingX classes aren't documented apart from comments in the code where they are defined. -- nosy: +mivade ___ Python tracker

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Change by Brett Hannigan : -- versions: -Python 3.10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Vinay Sajip added the comment: This is a change in behaviour, so probably needs to be added to future versions only. -- nosy: +vinay.sajip versions: +Python 3.10 -Python 3.7 ___ Python tracker

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 1.0 -> 2.0 pull_requests: +20398 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21248 ___ Python tracker

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

lack iterators and ConvertingDict lacks items() type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue41177> ___ ___ Python-bugs-list mailin

[issue41030] Provide toList() method on iterators/generators (`list()` is a flow killer in REPL)

Zachary Ware added the comment: Hi Julien, Thanks for the suggestion, but I agree with Ammar and Remi that this is not likely to either be easily doable or actually help your case. This would also be a big enough change to likely need a PEP. If you still want to pursue this I would

[issue41030] Provide toList() method on iterators/generators (`list()` is a flow killer in REPL)

Rémi Lapeyre added the comment: It would not work, an iterator is just a thing that has __next__() and __iter__(): class MyIterator: def __iter__(self): return self def __next__(self): return 1 Plenty of iterators would not have this method even if we added it to some of them

[issue41030] Provide toList() method on iterators/generators (`list()` is a flow killer in REPL)

Julien H added the comment: Hello Ammar Askar, I agree `_` avoids the "up arrow" problem I mentioned in the REPL. I actually primarily use jupyter notebooks in my work. Point 1. in my first message is the primary issue. Having to edit the line in two places to perform one action has

[issue41030] Provide toList() method on iterators/generators (`list()` is a flow killer in REPL)

Change by Julien H : -- title: Provide toList() method on iterators (`list()` is a flow killer in REPL) -> Provide toList() method on iterators/generators (`list()` is a flow killer in REPL) ___ Python tracker <https://bugs.python.org/issu

[issue41030] Provide toList() method on iterators/generators (`list()` is a flow killer in REPL)

Ammar Askar added the comment: Julien, in the REPL "_" represents the last evaluated expression. So you can do: >>> iter(range(10)) >>> list(_) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Do you feel like that covers what you're asking for? -- nosy: +ammar2

[issue41030] Provide toList() method on iterators (`list()` is a flow killer in REPL)

Change by Julien H : -- components: +Library (Lib) -Demos and Tools versions: -Python 3.9 ___ Python tracker ___ ___

[issue41030] Provide toList() method on iterators (`list()` is a flow killer in REPL)

Julien Edmond René Harbulot added the comment: Consider how easy in the REPL it is to hit `up arrow` and then append code to the previously entered command, compared to having to move the cursor back in the command to edit it somewhere in the middle. Simulated REPL session: ```

[issue41030] Provide toList() method on iterators (`list()` is a flow killer in REPL)

he problem with the current API is that: 1. I have to go back to my code and edit in several places to convert the iterators to lists. With the currrent way (i.e. `list( ... )`) I have to edit before the iterator to add `list(` and then after to add `)`. When my one-liners become complex, this is very tedious

[issue7105] weak dict iterators are fragile because of unpredictable GC runs

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7105] weak dict iterators are fragile because of unpredictable GC runs

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7105] weak dict iterators are fragile because of unpredictable GC runs

Change by Daniel Fortunov : -- nosy: +dfortunov nosy_count: 15.0 -> 16.0 pull_requests: +19902 pull_request: https://github.com/python/cpython/pull/20687 ___ Python tracker ___

[issue37708] Harmonize random.choice(s) behavior with random.sample on iterators

Change by Roundup Robot : -- nosy: +python-dev nosy_count: 3.0 -> 4.0 pull_requests: +18055 pull_request: https://github.com/python/cpython/pull/18694 ___ Python tracker ___

[issue39606] Regression: it should be possible to close async iterators multiple times

Change by Nathaniel Smith : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39606] Regression: it should be possible to close async iterators multiple times

Nathaniel Smith added the comment: New changeset f464edf3239f7867fe31c9cd238a68fb3b90feaa by Nathaniel J. Smith in branch '3.7': bpo-39606: allow closing async generators that are already closed (GH-18475) (GH-18502)

[issue39606] Regression: it should be possible to close async iterators multiple times

miss-islington added the comment: New changeset 8dbdf5f275c6462bb522bcf3a29054239d72989d by Miss Islington (bot) in branch '3.8': [3.8] bpo-39606: allow closing async generators that are already closed (GH-18475) (GH-18501)

[issue39606] Regression: it should be possible to close async iterators multiple times

Change by Nathaniel Smith : -- pull_requests: +17877 pull_request: https://github.com/python/cpython/pull/18502 ___ Python tracker ___

[issue39606] Regression: it should be possible to close async iterators multiple times

Change by miss-islington : -- pull_requests: +17875 pull_request: https://github.com/python/cpython/pull/18501 ___ Python tracker ___

[issue39606] Regression: it should be possible to close async iterators multiple times

miss-islington added the comment: New changeset 925dc7fb1d0db85dc137afa4cd14211bf0d67414 by Nathaniel J. Smith in branch 'master': bpo-39606: allow closing async generators that are already closed (GH-18475) https://github.com/python/cpython/commit/925dc7fb1d0db85dc137afa4cd14211bf0d67414

[issue39606] Regression: it should be possible to close async iterators multiple times

Change by Nathaniel Smith : -- keywords: +patch pull_requests: +17843 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18475 ___ Python tracker ___

[issue39606] Regression: it should be possible to close async iterators multiple times

- keywords: 3.7regression, 3.8regression, 3.9regression messages: 361783 nosy: asvetlov, lukasz.langa, ned.deily, njs, yselivanov priority: release blocker severity: normal status: open title: Regression: it should be possible to close async iterators multiple times versions: Python 3.7, Python 3.8,

[issue24659] dict() built-in fails on iterators with a "keys" attribute

Raymond Hettinger added the comment: This doesn't appear to have been an ongoing source of confusion. Over time, the existence of the glossary entries and the collections ABCs seems to have provided the needed clarity. -- resolution: -> out of date stage: needs patch -> resolved

[issue37708] Harmonize random.choice(s) behavior with random.sample on iterators

Raymond Hettinger added the comment: The sample() function accepts d.keys() because a keys view is registered as being an instance of collections.abc.Set. We have to do that because sample() is specifically documented as accepting sets. If we had it do over again, that functionality would

[issue37708] Harmonize random.choice(s) behavior with random.sample on iterators

Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37708] Harmonize random.choice(s) behavior with random.sample on iterators

Karthikeyan Singaravelan added the comment: Seems similar to https://bugs.python.org/issue37682 -- nosy: +rhettinger, xtreak ___ Python tracker ___

[issue37708] Harmonize random.choice(s) behavior with random.sample on iterators

New submission from Lex Flagel : It would be nice to make random.sample and random.choice both have the same behavior with iterators. Currently random.sample accepts them happily, and whereas random.choice does not. E.g. > import random > d = {'a':1, 'b':2} > random.sample(d.keys

[issue37682] random.sample should support iterators

Raymond Hettinger added the comment: Thomas, thank you for the suggestion but I think we should decline. The API for sample() is consistent with choice(), choices() and shuffle(). For the most part the sequence based API has worked out well. -- resolution: -> rejected stage: ->

[issue37682] random.sample should support iterators

Serhiy Storchaka added the comment: > ISTM that if a generator produces so much data that it is infeasible to fit > in memory, then it will also take a long time to loop over it and generate a > random value for each entry. Good point! $ ./python -m timeit -s 'from random import sample as

[issue37682] random.sample should support iterators

, the current approach works great with sample(range(100_000_000_000), k=50). We really don't have to make everything accept all iterators. Besides, it is trivially easy to call list() if needed. Overall, I'm -1 on redesigning the sampling algorithm to accommodate non-sequence iterators

[issue37682] random.sample should support iterators

Serhiy Storchaka added the comment: Possible implementation: from itertools import islice as _islice def reservoir_sample(self, population, k): if k < 0: raise ValueError("Sample is negative") it = iter(population) result = list(_islice(it, k)) if len(result) < k:

[issue37682] random.sample should support iterators

Serhiy Storchaka added the comment: FYI, random.sample() (as most of other functions in the random module) is implemented in pure Python. -- nosy: +serhiy.storchaka ___ Python tracker

[issue37682] random.sample should support iterators

Change by mental : -- nosy: +mark.dickinson, rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37682] random.sample should support iterators

algorithm as a pure python function, which is much slower, and not so easy. It seems that having a fast reservoir sampling implementation in `random.sample` to use for iterators would be both useful and make the API more predictable. Currently when passing an iterator `random.sample` throws

[issue33918] Hooking into pause/resume of iterators/coroutines

Change by Andrew Svetlov : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue33918] Hooking into pause/resume of iterators/coroutines

Andrew Svetlov added the comment: decimal was changed from threading.local to contextvar usage. The module is "safe" not only for asyncio but for threading, trio etc. unittest.mock doesn't use explicit context all for patching. It changes global interpreter-wide objects instead. So,

[issue31155] Encode set, frozenset, bytearray, and iterators as json arrays

Inada Naoki added the comment: I concur with Raymond. If you really need this feature, please discuss on python-dev ML. -- nosy: +inada.naoki resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue7877] Iterators over _winreg EnumKey and EnumValue results

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

STINNER Victor added the comment: Thanks Pablo for the fix ;-) -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

Pablo Galindo Salgado added the comment: New changeset 3766f18c524c57784eea7c0001602017d2122156 by Pablo Galindo in branch 'master': bpo-35378: Fix multiprocessing.Pool references (GH-11627) https://github.com/python/cpython/commit/3766f18c524c57784eea7c0001602017d2122156 --

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

Change by Pablo Galindo Salgado : -- pull_requests: +11392, 11393, 11394 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

Change by Pablo Galindo Salgado : -- pull_requests: +11392 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

Change by Pablo Galindo Salgado : -- pull_requests: +11392, 11393 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

STINNER Victor added the comment: According to all previous discussions, I now agree with having a strong reference. -- ___ Python tracker ___

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

Change by Raymond Hettinger : -- nosy: +davin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

tzickel added the comment: +1 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

Pablo Galindo Salgado added the comment: I have been playing with possible solutions for a while and the weak-reference solution seems not robust enough as there are too potential race conditions between the destruction of the weakreferences (the pool) and the handling code. I would

  1   2   3   4   5   6   7   8   >