[issue414743] Access violation in call to map

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

[issue47157] bijective invertible map

Jonathan Balloch added the comment: thank you!! On Tue, Mar 29, 2022 at 8:44 PM Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > This is indeed a duplicate. If needed just use one of implementations on > PyPI https://pypi.org/project/bidict/ > > -- > nosy:

[issue47157] bijective invertible map

Raymond Hettinger added the comment: This is indeed a duplicate. If needed just use one of implementations on PyPI https://pypi.org/project/bidict/ -- nosy: +rhettinger resolution: -> duplicate stage: -> resolved status: open -> closed ___

[issue47157] bijective invertible map

Dennis Sweeney added the comment: see also https://bugs.python.org/issue44931 -- nosy: +Dennis Sweeney ___ Python tracker ___ ___

[issue47157] bijective invertible map

New submission from Jonathan Balloch : It would be powerful to have a native implementation of a bijective map (e.g. a dictionary that hashed only one-to-one, but as a result either the "key" or the "value" could do lookup in O(1) time with the only overhead being th

[issue12506] NIS module cant handle multiple NIS map entries for the same GID

Irit Katriel added the comment: nis is deprecated as per PEP 594, so there won't be further enhancements to it. -- nosy: +iritkatriel resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker

[issue46621] Should map(function, iterable, ...) replace StopIteration with RuntimeError?

Vedran Čačić added the comment: Just for the record, I consider PEP 479 one of (very rare) design bugs in Python, and would like it reversed some day. (So anything that helps this outcome, including -1 on this, is welcome.) It subverts the natural property of exceptions (that they bubble

[issue46621] Should map(function, iterable, ...) replace StopIteration with RuntimeError?

Raymond Hettinger added the comment: -1 for being a breaking change, for addressing a minor issue that rarely arises in real life, and for being a slippery slope. -- nosy: +rhettinger ___ Python tracker

[issue46621] Should map(function, iterable, ...) replace StopIteration with RuntimeError?

New submission from Peiran Yao : Currently, StopIteration raised accidentally inside the `function` being applied is not caught by map(). This will cause the iteration of the map object to terminate silently. (Whereas, when some other exception is raised, a traceback is printed pinpointing

[issue23289] concurrent.futures.Executor.map is not equivalent to map.

Change by Irit Katriel : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Clarify map API in concurrent.futures ___ Python tracker <https://bugs.python

[issue31914] Document Pool.(star)map return type

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

[issue31914] Document Pool.(star)map return type

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

[issue31914] Document Pool.(star)map return type

Change by miss-islington : -- keywords: +patch, patch nosy: +miss-islington, miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +28411, 28412 stage: backport needed -> patch review pull_request: https://github.com/python/cpython/pull/30191 ___

[issue31914] Document Pool.(star)map return type

Change by miss-islington : -- keywords: +patch nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +28411 stage: backport needed -> patch review pull_request: https://github.com/python/cpython/pull/30191 ___ Python tracker

[issue31914] Document Pool.(star)map return type

Alex Waygood added the comment: PR 30191 and PR 30192 are backports -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue31914] Document Pool.(star)map return type

Alex Waygood added the comment: This appears to have been fixed in PR 26560 in the main branch, but it might be nice to backport it to 3.10 and 3.9 -- nosy: +AlexWaygood, mdk stage: -> backport needed type: enhancement -> behavior versions: +Python 3.10, Python 3.9 -Python 3.6

[issue45856] [doc] map() documentation ambiguous about consumption order

to make sure the code would behave as I expected. Not being able to find it explained in the documentation, I felt uncomfortable relying on an implicit behavior. After all, doesn't the PEP 20 state that "Explicit is better than implicit"? > In the context of map() however this te

[issue45856] [doc] map() documentation ambiguous about consumption order

Raymond Hettinger added the comment: I don't think this suggestion is helpful or necessary. The map() docs have been around for a long time and this hasn't proven to be a point of confusion. The itertools docs already have a recipe demonstrating the technique of passing the same

[issue45856] [doc] map() documentation ambiguous about consumption order

Change by Raymond Hettinger : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue45856] [doc] map() documentation ambiguous about consumption order

New submission from Thibaut Horel : In cases where multiple iterables are passed to the built-in function map(), the documentation is ambiguous about the order in which they are consumed [1]. Although the order of evaluation of function arguments is documented to be left-to-right in general

[issue45443] 'ThreadPoolExecutor' object has no attribute 'map'

Dennis Sweeney added the comment: It's been a couple of weeks, so I'm closing this. Feel free to re-open if you figure out that this is a bug that you can reliably reproduce on a fresh install of cpython. -- resolution: -> not a bug stage: -> resolved status: pending -> closed

[issue22294] 2to3 consuming_calls: len, min, max, zip, map, reduce, filter, dict, xrange

Change by Irit Katriel : -- resolution: -> wont fix stage: -> resolved status: open -> closed superseder: -> Close 2to3 issues and list them here ___ Python tracker ___

[issue45443] 'ThreadPoolExecutor' object has no attribute 'map'

Change by Dennis Sweeney : -- components: +Library (Lib) status: open -> pending type: crash -> behavior ___ Python tracker ___ ___

[issue45443] 'ThreadPoolExecutor' object has no attribute 'map'

repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'map', 'shutdown', 'submit'] -- nosy: +Dennis Sweeney ___ Python tracker <https://bugs.python.org/issue45443> ___

[issue45443] 'ThreadPoolExecutor' object has no attribute 'map'

Zohim Chandani added the comment: Please see attached. I have printed out the python version. Running this on VS code. -- Added file: https://bugs.python.org/file50353/Screenshot 2021-10-13 at 12.45.04.png ___ Python tracker

[issue45443] 'ThreadPoolExecutor' object has no attribute 'map'

Gregory Beauregard added the comment: I get no attribute error with this code in 3.9 or 3.10. -- nosy: +GBeauregard ___ Python tracker ___

[issue45443] 'ThreadPoolExecutor' object has no attribute 'map'

perfectly before. Did the method get removed? -- messages: 403723 nosy: zohim priority: normal severity: normal status: open title: 'ThreadPoolExecutor' object has no attribute 'map' type: crash versions: Python 3.9 ___ Python tracker <ht

[issue45378] Can't find "map" with search on docs.python.org

Terry J. Reedy added the comment: The iterator classes are not identified as such because being a class instead of a function, such as a generator function, is a CPython implementation detail, not a language requirement. Searching for filter seems as bad -- builtin filter is about the 60th

[issue45378] Can't find "map" with search on docs.python.org

Guido van Rossum added the comment: > I'm surprised no one else noticed this until now. Most people probably just use Google and read whatever comes up. I was looking whether the official docs for map mentioned that map is actually an iterator class. (They do

[issue45378] Can't find "map" with search on docs.python.org

Raymond Hettinger added the comment: I'm surprised no one else noticed this until now. The doc search finds some entries such as: "sum", "min", "max", and "enumerate". However, it is missing others such as: "map

[issue45378] Can't find "map" with search on docs.python.org

Change by Raúl Cumplido : -- nosy: +raulcd ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45378] Can't find "map" with search on docs.python.org

New submission from Guido van Rossum : I was looking for the docs for 'map' and tried to use the search box on docs.python.org. This gave a lot of things whose name started with or contained 'map', but the entry for the builtin map() function was hidden really far down under the heading

[issue45225] use map function instead of genexpr in capwords

Raymond Hettinger added the comment: Thanks for the PR. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue45225] use map function instead of genexpr in capwords

Raymond Hettinger added the comment: New changeset a59ede244714455aa9ee8637608e019a20fa2ca6 by speedrun-program in branch 'main': bpo-45225: use map function instead of genexpr in capwords (GH-28342) https://github.com/python/cpython/commit/a59ede244714455aa9ee8637608e019a20fa2ca6

[issue45225] use map function instead of genexpr in capwords

New submission from speedrun-program : In string.py, the capwords function passes str.join a generator expression, but the map function could be used instead. This is how capwords is currently written: ```py def capwords(s, sep=None): """capwords(s [,

Re: Scraping of Google Map to get the address of locations for given geocodes.

On 2021-09-02 at 20:12:19 -0300, Michio Suginoo wrote: > I have the following question regarding how to scrape Google Map to get > address based on a given list of geocodes. > Given a list of geocodes (latitude; longitude) of locations, I would like > to scrape municipalities of a

Scraping of Google Map to get the address of locations for given geocodes.

Dear all, I have the following question regarding how to scrape Google Map to get address based on a given list of geocodes. Given a list of geocodes (latitude; longitude) of locations, I would like to scrape municipalities of all the spots in the list. How can I do that? For example, I have

[issue44931] Add "bidimap" to collections library: a simple bidirectional map

Raymond Hettinger added the comment: This has come up several times in the past and never moved forward. Part of the reason is that the mapping API doesn't translate cleanly to bidirectional lookups and it leaves users trapped if two keys every end up needing to be mapped to the same value

[issue44931] Add "bidimap" to collections library: a simple bidirectional map

Vedran Čačić added the comment: Your implementation has many problems. First, almost all your complexity claims are wrong, probably because you copied them from Java, which uses balanced trees instead of Python's hash tables. (Also, the method names seem to be copied from Java, using

[issue44931] Add "bidimap" to collections library: a simple bidirectional map

Jurjen N.E. Bos added the comment: It is part of the Apache Common collections -- ___ Python tracker ___ ___ Python-bugs-list

[issue44931] Add "bidimap" to collections library: a simple bidirectional map

Serhiy Storchaka added the comment: Is BiDiMap included in the Java SDK? -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue44931] Add "bidimap" to collections library: a simple bidirectional map

Change by Jurjen N.E. Bos : -- title: Add "bidimap" to collections library -> Add "bidimap" to collections library: a simple bidirectional map ___ Python tracker <https://

[issue44437] Add multimap() function similar to map(), but with multiprocessing functionality to the multiprocessing module

New submission from Raymond Hettinger : Marking as closed for the reasons mentioned in the PR. I you want to go forward, consider starting a thread on python-ideas. -- nosy: +rhettinger resolution: -> rejected stage: patch review -> resolved status: open -> closed

[issue44437] Add multimap() function similar to map(), but with multiprocessing functionality to the multiprocessing module

Change by Ryan Rudes : -- components: +Library (Lib) -Tkinter ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44437] Add multimap() function similar to map(), but with multiprocessing functionality to the multiprocessing module

Change by Ryan Rudes : -- keywords: +patch pull_requests: +25347 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26762 ___ Python tracker ___

[issue44437] Add multimap() function similar to map(), but with multiprocessing functionality to the multiprocessing module

Change by Ryan Rudes : -- components: Tkinter nosy: Ryan-Rudes priority: normal severity: normal status: open title: Add multimap() function similar to map(), but with multiprocessing functionality to the multiprocessing module type: enhancement versions: Python 3.10, Python 3.11

[issue43575] map() instantiation time reducing by using PEP 590 vectorcall

Change by Dong-hee Na : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue43575] map() instantiation time reducing by using PEP 590 vectorcall

Dong-hee Na added the comment: New changeset 86883d40e93acae980e52b90fddd7d042e439beb by Dong-hee Na in branch 'master': bpo-43575: Use PEP 590 vectorcall to speed up map() (GH-24955) https://github.com/python/cpython/commit/86883d40e93acae980e52b90fddd7d042e439beb

[issue43575] map() instantiation time reducing by using PEP 590 vectorcall

Change by Karthikeyan Singaravelan : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43575] map() instantiation time reducing by using PEP 590 vectorcall

Change by Dong-hee Na : -- keywords: +patch pull_requests: +23714 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24955 ___ Python tracker ___

[issue43575] map() instantiation time reducing by using PEP 590 vectorcall

New submission from Dong-hee Na : +---+--+--+ | Benchmark | map_bench_master | map_bench_vectorcall | +===+==+==+ | bench map | 151 ns | 116 ns: 1.30x faster

[issue43217] tkinter style map return value in alt theme

Serhiy Storchaka added the comment: Tested on Python 3.8.6 and 3.8.7+, Windows 10. On 3.8.6 the bug is reproduced, on 3.8.7+ all works as expected. -- resolution: -> out of date stage: -> resolved status: open -> closed superseder: -> ttk style.map function incorrectly handles the

[issue43217] tkinter style map return value in alt theme

misianne added the comment: Tested W10 Python 3.9.1: map output is OK. It is a problem of Python 3.8.6 under W7. -- ___ Python tracker <https://bugs.python.org/issue43

[issue43217] tkinter style map return value in alt theme

misianne added the comment: My os is windows 7, Python 3.8.6. Obviously, I can't test it on 3.9+. -- ___ Python tracker ___ ___

[issue43217] tkinter style map return value in alt theme

Serhiy Storchaka added the comment: What is our OS and Python version. I cannot reproduce this on Linux, perhaps it is OS-specific. Try to test with the latest Python release. Maybe this bug was fixed in issue42328. -- nosy: +serhiy.storchaka

[issue43217] tkinter style map return value in alt theme

New submission from misianne : The return value for ttk.style().map('Treeview') is wrong for the 'background' value in the 'alt' theme: tuple are missing. Tcl alt Treeview map: -foreground {disabled #a3a3a3 {!disabled !selected} black selected #ff} -background {disabled #d9d9d9

[issue38661] Changes to tkinter result in (unexpected) widget map call return changes wrt. 3.7

Change by Serhiy Storchaka : -- stage: -> resolved status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue38661] Changes to tkinter result in (unexpected) widget map call return changes wrt. 3.7

Serhiy Storchaka added the comment: This was likely caused by different versions of Tk. It should be fixed now in issue42328. Style.map() should convert result to uniform representation on all versions and platforms, and accept input in different forms. Please check. -- resolution:

[issue42320] unexpected difference between map and list

Pierre van de Laar added the comment: Not a bug: tuple is an iterator but an iterator is not a tuple. Yet iterators are often accepted during initialization... -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python

[issue42320] unexpected difference between map and list

Pierre van de Laar added the comment: Zip didn't contain the test cases from the tests directory (sorry for that) -- Added file: https://bugs.python.org/file49592/tests.zip ___ Python tracker

[issue42320] unexpected difference between map and list

New submission from Pierre van de Laar : On windows, with python 3.9, with unittests, My test case fails when I use the following lines of code ``` result = map(lambda x: self.substitute_in_expression(x), sequence.sequence) ``` It works fine with ``` result = list() for x

[issue41588] Potential Memory leak with concurrent.futures.ThreadPoolExecutor's map

Change by Kyle Stanley : -- nosy: +aeros, bquinlan, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41588] Potential Memory leak with concurrent.futures.ThreadPoolExecutor's map

` with the map function, and passing a dictionary to the map's function as an argument, the memory used by the pool won't be freed and as a result the total memory consumption will continue to rise. (Seems like it also happens when passing a list and maybe even other types). Here is an example of a code

[issue41407] Tricky behavior of builtin-function map

Raymond Hettinger added the comment: I concur with Jim and Steven, so we'll mark this a closed. If you want to go forward, consider bringing this up on python-ideas. If it gets a favorable reception, this can be re-opened. -- nosy: +rhettinger resolution: -> rejected stage: ->

[issue41407] Tricky behavior of builtin-function map

Jim Jewett added the comment: Why would you raise StopIteration if you didn't want to stop the nearest iteration loop? I agree that the result of your sample code seems strange, but that is because it is strange code. I agree with Steven D'Aprano that changing it would cause more pain than

[issue41407] Tricky behavior of builtin-function map

was raised about comprehensions), but I argue that this is not a bug it is a useful feature. Having the map function raise StopIteration is a good way for the map to halt the loop early, when it detects a special sentinel or condition. A few years ago the change to comprehensions broke my code so I

[issue41407] Tricky behavior of builtin-function map

StopIteration # Suppose this function will do some simple calculation return -param # Then when we use builtin-function `map` and for-loop: print('example 1'.center(30, '=')) for item in map(raise_stop_iteration, range(5)): print(item) print('end of example 1'.center(30, '=')) # It works

[issue41107] Running a generator in a map-like manner

Raymond Hettinger added the comment: FWIW, you can already do this with map() and deque(): deque(map(f, it), maxsize=0) -- ___ Python tracker <https://bugs.python.org/issue41

[issue41107] Running a generator in a map-like manner

Natsumi H. added the comment: If it won't be added do you reckon creating a library to solve this issue would be appropriate? -- ___ Python tracker ___

[issue41107] Running a generator in a map-like manner

Rémi Lapeyre added the comment: I don't think something so obvious can be added, if you want a one liner you can write: for e in iterable: f(e) I think it would go in itertools if it were accepted. -- nosy: +rhettinger ___ Python tracker

[issue41107] Running a generator in a map-like manner

Natsumi H. added the comment: Exactly that was the plan! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41107] Running a generator in a map-like manner

Change by Rémi Lapeyre : -- components: +Library (Lib) -Interpreter Core ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue41107] Running a generator in a map-like manner

Rémi Lapeyre added the comment: If I'm understanding correctly you want: def xmap(f, iterable): for e in iterable: f(e) Is that correct? -- nosy: +remi.lapeyre ___ Python tracker

[issue41107] Running a generator in a map-like manner

New submission from Natsumi H. : I suggest adding a function which behaves like map but without returning anything to iterate over a generator. This is useful in cases where you need to run a function on every element in a list without unnecessarily creating a generator object like map would

[issue39673] Map errno==ETIME to TimeoutError

Eric V. Smith added the comment: Thanks for clarifying, Giampaolo. I'll accept this PR once it's cleaned up. -- ___ Python tracker ___

[issue39673] Map errno==ETIME to TimeoutError

Giampaolo Rodola' added the comment: Sigh! I misread the OP's post and thought the proposal was to add TimeoutError which I forgot existed. Sorry for the noise and please disregard my previous comment. -- ___ Python tracker

[issue39673] Map errno==ETIME to TimeoutError

Stephen J. Turnbull added the comment: First, let me say I like Giampaolo's TimeoutExpired *much* better as the name for this kind of exception! But that ship has sailed. I don't understand Giampaolo's comment. If I understand the claim correctly, the problem is that people who should be

[issue39673] Map errno==ETIME to TimeoutError

Giampaolo Rodola' added the comment: I'm -1 about TimeoutError because the concept of "timeout" is generic enough to be often implemented as a custom exception, which poses questions re. backward/forward compatibilty. E.g. in psutil I have "TimeoutExpired", also providing a "seconds"

[issue39673] Map errno==ETIME to TimeoutError

Change by Zackery Spytz : -- versions: +Python 3.10 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue39673] Map errno==ETIME to TimeoutError

Change by Zackery Spytz : -- keywords: +patch nosy: +ZackerySpytz nosy_count: 2.0 -> 3.0 pull_requests: +19538 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/20253 ___ Python tracker

[issue39673] Map errno==ETIME to TimeoutError

Change by Eric V. Smith : -- stage: -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39673] Map errno==ETIME to TimeoutError

Change by Eric V. Smith : -- title: TimeoutError -> Map errno==ETIME to TimeoutError type: behavior -> enhancement ___ Python tracker <https://bugs.python.org/i

[issue38661] Changes to tkinter result in (unexpected) widget map call return changes wrt. 3.7

Change by Juliette Monsel : -- nosy: +j-4321-i ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38661] Changes to tkinter result in (unexpected) widget map call return changes wrt. 3.7

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38661] Changes to tkinter result in (unexpected) widget map call return changes wrt. 3.7

New submission from Jose Salvatierra : Hello! I've encountered what might be a bug. Up till now we had some working code that did this: ``` maps = self.style.map('TCombobox') if maps: self.style.map('DateEntry', **maps) ``` Modifying a custom style to mimic the map of another. This has

[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)

STINNER Victor added the comment: The main issue with using length hint is that calling a method is Python is not free. Calling the method may add more overhead than the speedup provided by smarter memory allocations. The worst case for this optimization should be measured on very small

[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)

Nicholas Musolino added the comment: Before seeing this issue and its closed status, I created PR 14432, which adds `__length_hint__()` to the iterator returned by builtin `map`. This PR differs from the original 2017 PR by MSeifert in that the code can distinguish between the cases where

[issue37435] builtin map iterator should provide __length_hint__

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

[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)

Change by Nicholas Musolino : -- pull_requests: +14249 pull_request: https://github.com/python/cpython/pull/14432 ___ Python tracker ___

[issue37435] builtin map iterator should provide __length_hint__

Nicholas Musolino added the comment: Thanks, Serihy. I can close this issue. I actually have been looking at this problem for some time, and created a patch, but don't what the "length transparency issues" that led to #26828 being closed. Do you think I should close this and comment on

[issue37435] builtin map iterator should provide __length_hint__

Serhiy Storchaka added the comment: This is a duplicate of issue26828. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue37435] builtin map iterator should provide __length_hint__

Change by Nicholas Musolino : -- keywords: +patch pull_requests: +14248 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14432 ___ Python tracker

[issue37435] builtin map iterator should provide __length_hint__

New submission from Nicholas Musolino : The builtin `map` function takes one or more user-supplied iterators, and returns an iterator. When all the user-supplied iterator arguments to `map` provide a valid length hint (according to the PEP 424 length hint protocol), the iterator returned

[issue36923] Implemented __str__ for zip and map objects

Serhiy Storchaka added the comment: It will fail for infinite and very large iterables. It can cause performing unexpected operations. Examples: zip(itertools.count(), itertools.repeat(None)) zip(file1, file2) In general, the repr of the iterator should not change it state. But

[issue36923] Implemented __str__ for zip and map objects

SilentGhost added the comment: This would exhaust the object, seems like a rather unfortunate side effect. I don't think this suggestion has any chance of being accepted, do feel free to take it to python-ideas to demonstrate that benefits outweigh the downsides. -- nosy:

[issue36923] Implemented __str__ for zip and map objects

: 342556 nosy: AugPro priority: normal severity: normal status: open title: Implemented __str__ for zip and map objects type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue36

[issue23697] Module level map & submit for concurrent.futures

Josh Rosenberg added the comment: For the process based versions, it makes it too easy to accidentally fork bomb yourself, since each process that call psubmit would implicitly created another #CPUs workers of its own, so a process based version Brian's case with a mere four top-level

[issue23697] Module level map & submit for concurrent.futures

Brian Quinlan added the comment: Using a default executor could be dangerous because it could lead to deadlocks. For example: mylib.py def my_func(): tsubmit(...) tsubmit(...) tsubmit(somelib.some_func, ...) somelib.py -- def some_func(): tsubmit(...) # Potential

[issue12506] NIS module cant handle multiple NIS map entries for the same GID

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

Re: What is not working with my "map" usage?

ent from each nested list to add up [1,2,3] = 6. How should it be corrected? Thx. > >> alist = [[1,11,111], [2,22,222], [3,33,333]] > >> list(map(add_all_elements,*alist) > > Trylist(map(add_all_elements, alist)) instead. If you give a map a single list as a sec

  1   2   3   4   5   6   7   8   9   10   >