[issue414743] Access violation in call to map

[admin]

Change by admin :


--
github: None -> 34296

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47157] bijective invertible map

[Jonathan Balloch]

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: +rhettinger
> resolution:  -> duplicate
> stage:  -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47157] bijective invertible map

[Raymond Hettinger]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47157] bijective invertible map

[Dennis Sweeney]

Dennis Sweeney  added the comment:

see also https://bugs.python.org/issue44931

--
nosy: +Dennis Sweeney

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47157] bijective invertible map

[Jonathan Balloch]

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 the 
additional memory overhead of O(2N) as many references. 

Calling the object type "bimap", this could be easily implemented by simply 
having a call to bimap.inverse[value]=key, where the 'inverse' keyword is a 
reference table to the value-->key references. 

This is an important enhancement because currently the most efficient way to 
implement this is python is to, either: (1) make a custom object type that 
keeps two dictionaries, one that maps v->k and one that maps k->v, which takes 
twice as much memory, or (2) an object that has a custom "inverse" lookup call, 
which will be slower than O(1). In both cases there is no implicit enforcement 
of values being unique (necessary for a bijection). 

This should be added to the `collections` library as it will fit well along 
side other unique hashed collections such as "OrderedDict"

This will be beneficial to the community because transformations between 
semantic spaces (e.g. things that cannot be done in NumPy or similar) could be 
much more efficient and have cleaner, easier to read code if bijection maps 
were native and used one structure instead of two dictionaries.

--
components: Interpreter Core
messages: 416304
nosy: jon.balloch
priority: normal
severity: normal
status: open
title: bijective invertible map
type: enhancement
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue47157>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vedran Čačić]

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 through frames 
undisturbed until caught) for no benefit at all, and it has made me write 
almost every chained generator since then in a more complex way, adding 
boilerplate code that converts inner StopIteration to return. I'm sure many 
others have done so too. Ceterum censeo PEP479em esse delendam.

--
nosy: +veky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Peiran Yao]

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 the cause of the problem.)

Here's a minimal working example:

```
def take_first(it: Iterable):
# if `it` is empty, StopIteration will be raised accidentally
return next(it) 

iterables = [iter([1]), iter([]), iter([2, 3])] # the second one is empty
for i in map(take_first, iterables):
print(i)
```

`take_first` function didn't consider the case where `it` is empty. The 
programmer would expect an uncaught StopIteration, instead of the loop 
terminating silently after only one iteration.

Similar to the case of generators (described in PEP 497), this behaviour can 
conceal obscure bugs, and a solution could be catching StopIteration when 
applying the function, and replacing it with a RuntimeError.

Beside the built-in map(), imap() and imap_unordered() in the concurrent and 
multiprocessing modules also have similar behaviour.


PEP 479 -- Change StopIteration handling inside generators 
https://www.python.org/dev/peps/pep-0479/

--
messages: 412419
nosy: xavieryao
priority: normal
severity: normal
status: open
title: Should map(function, iterable, ...) replace StopIteration with 
RuntimeError?
type: behavior

___
Python tracker 
<https://bugs.python.org/issue46621>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Clarify map API in concurrent.futures

___
Python tracker 
<https://bugs.python.org/issue23289>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alex Waygood]

Change by Alex Waygood :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

Change by miss-islington :


--
pull_requests: +28413
pull_request: https://github.com/python/cpython/pull/30192

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alex Waygood]

Alex Waygood  added the comment:

PR 30191 and PR 30192 are backports

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alex Waygood]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Thibaut Horel]

Thibaut Horel  added the comment:

> this hasn't proven to be a point of confusion

Absence of evidence is not evidence of absence… The word "confusion" is 
probably a bit strong, but I recently had to write code relying on this 
behavior and found myself checking the documentation 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 technique is rarely, if ever, used.

I think use cases are more common than what might appear at first glance. For 
example, a file could contain information about a list of entities, each entity 
being described over two consecutive lines of the file (this is admittedly a 
bad format for a file, but such is the reality of real-world data…). Then, 
given a function `parse` constructing an internal representation of the entity 
from two lines, the list of entities can elegantly be constructed using 
`map(parse, file, file)`. The equivalent construction with `zip` would be 
something like `starmap(parse, zip(file, file))` which is unnecessary 
convoluted.

> the pure python code provided is likely only intelligible to someone who 
> already understands map()

The pure Python code expresses `map` in terms of other language constructs, so 
it is not clear to me why one would need to already understand `map()` to 
understand the provided code. This is similar to a dictionary definition, where 
a concept is explained in terms of other concepts. This is also similar to how 
related functions (like `starmap`) are explained in the `itertools` module.

Overall, I am curious about the rationale behind not making the documentation 
more explicit when possible.

--

___
Python tracker 
<https://bugs.python.org/issue45856>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 iterator multiple times with izip_longest().  That is a case where the 
technique is useful.  In the context of map() however this technique is rarely, 
if ever, used.

A last thought is that we do put in rough pure python equivalents when they 
help understand the function.  In this case though, the pure python code 
provided is likely only intelligible to someone who already understands map().

Thank you for the suggestion, but we should pass on this one.

--
nosy: +rhettinger

___
Python tracker 
<https://bugs.python.org/issue45856>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Thibaut Horel]

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 [2], this does not necessarily imply that the 
__next__() functions of the underlying iterators are called from left to right 
*before* passing the returned elements to the function being mapped. This is 
particularly relevant when the same iterator is passed multiple times, or when 
there are side effects to consuming the iterables.

I suggest adding the sentence “The iterables are consumed in left-to-right 
order at each iteration.”, similar to how it is done for the function zip() 
[3]. Furthermore, I think providing the following (roughly) equivalent 
implementation in pure Python might be illuminating:

def map(function, *iterables):
iterators = tuple(iter(it) for it in iterables)
while True:
try:
args = [next(it) for it in iterators]
except StopIteration:
break
yield func(*args)


Finally, the following example could be added. “This makes it possible to apply 
a function to consecutive groups of elements from the same iterator by passing 
it multiple times to `map`:

from itertools import count

ctr = count()
# map(func, ctr, ctr) -> func(0, 1), func(2, 3), ...
 
”

I am happy to submit a pull request once we reach a consensus on the 
formulation.

[1] https://docs.python.org/3/library/functions.html#map
[2] https://docs.python.org/3/reference/expressions.html#evaluation-order
[3] https://docs.python.org/3/library/functions.html#zip

--
assignee: docs@python
components: Documentation
messages: 406693
nosy: docs@python, eric.araujo, ezio.melotti, mdk, thibaut.horel, willingc
priority: normal
severity: normal
status: open
title: [doc] map() documentation ambiguous about consumption order
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 
<https://bugs.python.org/issue45856>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dennis Sweeney]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
superseder:  -> Close 2to3 issues and list them here

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dennis Sweeney]

Change by Dennis Sweeney :


--
components: +Library (Lib)
status: open -> pending
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dennis Sweeney]

Dennis Sweeney  added the comment:

I was also unable to replicate on any of 3.7-3.11, including 3.9.6. Is it 
possible that one of your Python stdlib source files was modified? Does this 
still happen with a fresh install of Python?

Does your problem still happen if you run the file using a python executable 
directly rather than using IPython/Jupyter? If it's just a problem with 
Jupyter, this bug report belongs there.

Can you run:

>>> from concurrent.futures import ThreadPoolExecutor as TPE
>>> TPE.__mro__
(, , )
>>> TPE.__mro__[1]

>>> dir(TPE.__mro__[1])
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__enter__', 
'__eq__', '__exit__', '__format__', '__ge__', '__getattribute__', '__gt__', 
'__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', 
'__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', 
'__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'map', 'shutdown', 
'submit']

--
nosy: +Dennis Sweeney

___
Python tracker 
<https://bugs.python.org/issue45443>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Zohim Chandani]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gregory Beauregard]

Gregory Beauregard  added the comment:

I get no attribute error with this code in 3.9 or 3.10.

--
nosy: +GBeauregard

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Zohim Chandani]

New submission from Zohim Chandani :

import concurrent.futures 
import time 


start = time.perf_counter()

def do_something(seconds):
print(f'sleeping for {seconds}s ... ')
time.sleep(seconds)
return f'done sleeping {seconds} '


with concurrent.futures.ThreadPoolExecutor() as executor: 

secs = [5,4,3,2,1]

results = executor.map(do_something, secs)

for result in results: 
print(result)




finish = time.perf_counter()

print(f'finished in {round(finish-start, 2)} seconds')



The above code yields an attribute error whereas it used to execute 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 
<https://bugs.python.org/issue45443>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry J. Reedy]

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 hit.  
Builtins should be listed first instead.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 don't.)

--

___
Python tracker 
<https://bugs.python.org/issue45378>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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" and "filter".

--
nosy: +rhettinger

___
Python tracker 
<https://bugs.python.org/issue45378>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raúl Cumplido]

Change by Raúl Cumplido :


--
nosy: +raulcd

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 "Builtin Functions" 
(https://docs.python.org/3.10/library/functions.html?highlight=map) rather than 
deep-linking to the entry I was looking for 
(https://docs.python.org/3.10/library/functions.html#map).

I'm sure that some tweak to the index builder could fix this, in general, for 
all builtin functions and types (many of which I imagine suffer from the effect 
-- having a short name that is used a lot as a part of other names).

--
assignee: docs@python
components: Documentation
messages: 403245
nosy: docs@python, gvanrossum
priority: normal
severity: normal
status: open
title: Can't find "map" with search on docs.python.org
type: behavior

___
Python tracker 
<https://bugs.python.org/issue45378>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45225] use map function instead of genexpr in capwords

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the PR.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45225] use map function instead of genexpr in capwords

[Raymond Hettinger]

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


--
nosy: +rhettinger

___
Python tracker 
<https://bugs.python.org/issue45225>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45225] use map function instead of genexpr in capwords

[speedrun-program]

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 [,sep]) -> string

Split the argument into words using split, capitalize each
word using capitalize, and join the capitalized words using
join.  If the optional second argument sep is absent or None,
runs of whitespace characters are replaced by a single space
and leading and trailing whitespace are removed, otherwise
sep is used to split and join the words.

"""
return (sep or ' ').join(x.capitalize() for x in s.split(sep))
```


This is how capwords could be written:


```py
def capwords(s, sep=None):
"""capwords(s [,sep]) -> string

Split the argument into words using split, capitalize each
word using capitalize, and join the capitalized words using
join.  If the optional second argument sep is absent or None,
runs of whitespace characters are replaced by a single space
and leading and trailing whitespace are removed, otherwise
sep is used to split and join the words.

"""
return (sep or ' ').join(map(str.capitalize, s.split(sep)))
```


These are the benefits:

1. Faster performance which increases with the number of times the str is split.

2. Very slightly smaller .py and .pyc file sizes.

3. Source code is slightly more concise.

This is the performance test code in ipython:


```py
def capwords_current(s, sep=None):
return (sep or ' ').join(x.capitalize() for x in s.split(sep))
​
def capwords_new(s, sep=None):
return (sep or ' ').join(map(str.capitalize, s.split(sep)))
​
tests = ["a " * 10**n for n in range(9)]
tests.append("a " * (10**9 // 2)) # I only have 16GB of RAM
```


These are the results of a performance test using %timeit in ipython:



%timeit x = capwords_current("")
835 ns ± 15.2 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)

%timeit x = capwords_new("")
758 ns ± 35.1 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[0])
977 ns ± 16.9 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)

%timeit x = capwords_new(tests[0])
822 ns ± 30 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[1])
3.07 µs ± 88.8 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

%timeit x = capwords_new(tests[1])
2.17 µs ± 194 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[2])
28 µs ± 896 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)

%timeit x = capwords_new(tests[2])
19.4 µs ± 352 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[3])
236 µs ± 14.5 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

%timeit x = capwords_new(tests[3])
153 µs ± 2 µs per loop (mean ± std. dev. of 7 runs, 1 loops each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[4])
2.12 ms ± 106 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

%timeit x = capwords_new(tests[4])
1.5 ms ± 9.61 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[5])
23.8 ms ± 1.38 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

%timeit x = capwords_new(tests[5])
15.6 ms ± 355 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[6])
271 ms ± 10.6 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit x = capwords_new(tests[6])
192 ms ± 807 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[7])
2.66 s ± 14.3 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit x = capwords_new(tests[7])
1.95 s ± 26.7 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[8])
25.9 s ± 80.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit x = capwords_new(tests[8])
18.4 s ± 123 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
- - - - - - - - - - - - - - - - - - - - 
%timeit x = capwords_current(tests[9])
6min 17s ± 29 s per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit x = capwords_new(tests[9])
5min 36s ± 24.8 s per loop (mean ± std. dev. of 7 runs, 1 loop each)

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

[2QdxY4RzWzUUiLuE]

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 all the spots in the list. How can I do that?
> 
> For example, I have
> 
>   lat  lon
> 
> 1) -34.5722317  -58.4314464
> 
> 2) -34.553906   -58.4520949
> 
> 3) -34.5661444  -58.4964289
> 
> 4) -34.5648053  -58.4431567
> 
> 5) -34.5664089  -58.4323004
> 
> 6) -34.5664089  -58.4323004
> 
> 
> 
> And I want to get the name of municipality (city/town), or alternatively
> the address, of each location.
> 
> 
> I would appreciate it, if anyone can advise me how to do that.

Is scraping Google Map a hard requirement?

Both geopy¹ and geocoder² can translate those coordinates into street
addresses directly, and their documentation even explains how to bypass
the libraries and go straight to the service providers.

¹ https://geopy.readthedocs.io/en/latest/
² https://geocoder.readthedocs.io/
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Michio Suginoo]

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

  lat  lon

1) -34.5722317  -58.4314464

2) -34.553906   -58.4520949

3) -34.5661444  -58.4964289

4) -34.5648053  -58.4431567

5) -34.5664089  -58.4323004

6) -34.5664089  -58.4323004



And I want to get the name of municipality (city/town), or alternatively
the address, of each location.


I would appreciate it, if anyone can advise me how to do that.


Thanks

Best regards

Michio
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Raymond Hettinger]

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 (i.e. libre->free and gratis->free). Mostly, folks are 
better-off with two separate dictionaries augmented by a single function to 
create the initial pairing.  Also note that there are several bimaps published 
on PyPi but they have very low uptake.

If you want to pursue this further, I suggest bringing this to python-ideas 
(but first scan the archives for previous discussions and scan github for cases 
where projects have used one of the existing implementations).

--
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vedran Čačić]

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 camelCase which is 
unusual for Python stdlib.)

Second, shouldn't _inverse be a weakkey dictionary? Otherwise many operations 
(e.g. removeValue) will get two dicts out of sync quickly.

--
nosy: +veky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jurjen N.E. Bos]

Jurjen N.E. Bos  added the comment:

It is part of the Apache Common collections

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Is BiDiMap included in the Java SDK?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jurjen N.E. Bos]

Change by Jurjen N.E. Bos :


--
title: Add "bidimap" to collections library -> Add "bidimap" to collections 
library: a simple bidirectional map

___
Python tracker 
<https://bugs.python.org/issue44931>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ryan Rudes]

Change by Ryan Rudes :


--
components: +Library (Lib) -Tkinter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ryan Rudes]

Change by Ryan Rudes :


--
keywords: +patch
pull_requests: +25347
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26762

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ryan Rudes]

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, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44437>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dong-hee Na]

Change by Dong-hee Na :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dong-hee Na]

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


--

___
Python tracker 
<https://bugs.python.org/issue43575>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dong-hee Na]

Change by Dong-hee Na :


--
keywords: +patch
pull_requests: +23714
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24955

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dong-hee Na]

New submission from Dong-hee Na :

+---+--+--+
| Benchmark | map_bench_master | map_bench_vectorcall |
+===+==+==+
| bench map | 151 ns   | 116 ns: 1.30x faster |
+---+--+--+

We already apply this feature for filter().
No reason not to apply map().

--
assignee: corona10
components: Interpreter Core
files: map_bench.py
messages: 389210
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: map() instantiation time reducing by using PEP 590 vectorcall
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file49896/map_bench.py

___
Python tracker 
<https://bugs.python.org/issue43575>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43217] tkinter style map return value in alt theme

[Serhiy Storchaka]

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 default state 
for element options.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43217] tkinter style map return value in alt theme

[misianne]

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/issue43217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43217] tkinter style map return value in alt theme

[misianne]

misianne  added the comment:

My os is windows 7, Python 3.8.6. 
Obviously, I can't test it on 3.9+.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43217] tkinter style map return value in alt theme

[Serhiy Storchaka]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43217] tkinter style map return value in alt theme

[misianne]

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 {!disabled !selected} #ff selected #4a6984}


tkinter alt Treeview map:

{
'foreground': [('disabled', '#a3a3a3'), ('!disabled', '!selected', 'black'), 
('selected', '#ff')], 
'background': ['disabled', '#d9d9d9', '!disabled !selected', '#ff', 
'selected', '#4a6984']
}

It should be:

'background': [('disabled', '#d9d9d9'), ('!disabled !selected', '#ff'), 
('selected', '#4a6984')]

--
components: Tkinter
messages: 386930
nosy: misianne
priority: normal
severity: normal
status: open
title: tkinter style map return value in alt theme
type: behavior
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue43217>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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:  -> duplicate
status: open -> pending
superseder:  -> ttk style.map function incorrectly handles the default state 
for element options.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42320] unexpected difference between map and list

[Pierre van de Laar]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42320] unexpected difference between map and list

[Pierre van de Laar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42320] unexpected difference between map and list

[Pierre van de Laar]

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 in sequence.sequence:
 result.append(self.substitute_in_expression(x))
```

Note that result is used as input for an inherited class instantiation:
```
sequence_type = type(sequence)
return sequence_type(result)
```
The classes are constructed using the dataclass decorator!


I have unfortunately not have time to make a small reproducer.
So I just send the whole project.

--
files: bug.zip
messages: 380742
nosy: Pierre van de Laar
priority: normal
severity: normal
status: open
title: unexpected difference between map and list
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49591/bug.zip

___
Python tracker 
<https://bugs.python.org/issue42320>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: +aeros, bquinlan, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Or Yahalom]

New submission from Or Yahalom :

I've been debugging a high memory consumption in one of my scripts and traced 
it back to the `concurrent.futures.ThreadPoolExecutor`.

When further investigating and playing around, I found out that when using 
`concurrent.futures.ThreadPoolExecutor` 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 to recreate this issue:

```
#!/usr/bin/env python3

import os
import time
import psutil
import random
import concurrent.futures

from memory_profiler import profile as mem_profile

p = psutil.Process(os.getpid())

def do_magic(values):
return None

@mem_profile
def foo():
a = {i: chr(i) for i in range(1024)}
with concurrent.futures.ThreadPoolExecutor(max_workers=10) as pool:
proccessed_data = pool.map(do_magic, a)

def fooer():
while True:
foo()
time.sleep(1)

fooer()
```

--
components: Extension Modules
messages: 375647
nosy: or12
priority: normal
severity: normal
status: open
title: Potential Memory leak with concurrent.futures.ThreadPoolExecutor's map
type: resource usage
versions: Python 3.7

___
Python tracker 
<https://bugs.python.org/issue41588>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41407] Tricky behavior of builtin-function map

[Raymond Hettinger]

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:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41407] Tricky behavior of builtin-function map

[Jim Jewett]

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 it 
would remove.

Unless it gets a lot more support by the first week of August, I recommend 
closing this request as rejected.

--
nosy: +Jim.Jewett
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41407] Tricky behavior of builtin-function map

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Converting *all* exceptions into RuntimeError is certainly not a good idea, 
especially since you include KeyboardInterrupt and other non-errors.

I'm probably going to be on the losing side of this one (I lost the argument 
back when a similar issue 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 changed to map, and now you 
want to break it again :-(

--
nosy: +steven.daprano

___
Python tracker 
<https://bugs.python.org/issue41407>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41407] Tricky behavior of builtin-function map

[DarrenDanielDay]

New submission from DarrenDanielDay :

# The following is a tricky example:

# This is an example function that possibly raises `StopIteration`.
# In some cases, this function may raise `StopIteration` in the first iteration.
def raise_stop_iteration(param):
if param == 10:
raise 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 well. The output of example 1 is 0 to -4.
# But the following can be triky:

print('example 2'.center(30, '='))
for item in map(raise_stop_iteration, range(10, 20)):
print(item)
print('end of example 2'.center(30, '='))

# The output of exapmle 2 is just nothing,
# and no errors are reported,
# because `map` simply let the exception spread upward when executing 
`raise_stop_iteration(10)`.
# However, the exception type is StopIteration, so the for-loop catches it and 
breaks the loop,
# assuming this is the end of the loop.
# When the exception raised from buggy mapping function is exactly 
`StopIteration`, 
# for example, functions implemented with builtin-function `next`, 
# it can be confusing to find the real issue.

# I think it might be better improved in this way:

class my_map:
def __init__(self, mapping_function, *iterators):
self.mapping = mapping_function
self.iterators = iterators

def __iter__(self):
for parameter_tuple in zip(*self.iterators):
try:
yield self.mapping(*parameter_tuple)
except BaseException as e:
raise RuntimeError(*e.args) from e

# It works like the map in most cases:

print('example 3'.center(30, '='))
for item in my_map(raise_stop_iteration, range(5)):
print(item)
print('end of example 3'.center(30, '='))

# And then, the crash of the buggy mapping function will be reported:
print('example 4'.center(30, '='))
for item in my_map(raise_stop_iteration, range(10, 20)):
print(item)
print('end of example 4'.center(30, '='))

--
components: Library (Lib)
files: issue.py
messages: 374371
nosy: DarrenDanielDay
priority: normal
severity: normal
status: open
title: Tricky behavior of builtin-function map
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49342/issue.py

___
Python tracker 
<https://bugs.python.org/issue41407>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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/issue41107>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Natsumi H.]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Rémi Lapeyre]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Natsumi H.]

Natsumi H.  added the comment:

Exactly that was the plan!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Rémi Lapeyre]

Change by Rémi Lapeyre :


--
components: +Library (Lib) -Interpreter Core

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Rémi Lapeyre]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Natsumi H.]

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. 

I think given the existence of the map function that this should be added to 
Python.

--
components: Interpreter Core
messages: 372275
nosy: natsuwumi
priority: normal
severity: normal
status: open
title: Running a generator in a map-like manner
type: enhancement
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue41107>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39673] Map errno==ETIME to TimeoutError

[Eric V. Smith]

Eric V. Smith  added the comment:

Thanks for clarifying, Giampaolo. I'll accept this PR once it's cleaned up.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39673] Map errno==ETIME to TimeoutError

[Giampaolo Rodola']

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39673] Map errno==ETIME to TimeoutError

[Stephen J. Turnbull]

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 catching some application-specific 
exception may be misled into catching TimeoutError instead, or into trying to 
get application-specific attributes from TimeoutError.  But that ship sailed 
with the creation of TimeoutError.  (We have a whole fleet sailing with this 
exception.)  Unless Giampaolo is proposing to deprecate TimeoutError?  I'm 
sympathetic ;-), but deprecation is a PITA and takes forever.

If we're not going to deprecate, it seems to me that it's much more 
developer-friendly to catch ETIME with TimeoutError, as that seems very likely 
to be the expected behavior.  It's true that even if Giampaolo changes 
TimeoutExpired to subclass TimeoutError, generic TimeoutError won't have 
.seconds.  But if you catch a TimeoutExpired with TimeoutError, that instance 
*will* have .seconds, and if you try to get .seconds on generic TimeoutError, 
you'll get a different uncaught exception (AttributeError vs. TimeoutError), 
but that TimeoutError wouldn't have been handled by catching TimeoutExpired.

I agree with Eric that people who were distinguishing OSError with .errno=ETIME 
from TimeoutError might be at risk, but I wouldn't do that: if I were going to 
be distinguishing particular OSErrors on the basis of errno (other than in 
"Unexpected OSError (errno = %d)" reporting style), I'd just catch OSError and 
do that.  On the other hand, I might expect TimeoutError to catch ETIME.  And 
Giampaolo says he's never seen either.  I suppose the author of psutil would be 
as likely as anyone to have seen it!

On net (unless we go the deprecation route) it seems that the convenience and 
"intuition" of adding ETIME to TimeoutError outweighs that risk.

I wish there were somebody who was there at the creation of ETIME!

--
nosy: +sjt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39673] Map errno==ETIME to TimeoutError

[Giampaolo Rodola']

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" attribute. Also I've probably never seen ETIME / 
ETIMEDOUT happening, whereas AFAIU the point of PEP 3151 was to create mappings 
for the most common errnos.

--
nosy: +giampaolo.rodola

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39673] Map errno==ETIME to TimeoutError

[Zackery Spytz]

Change by Zackery Spytz :


--
versions: +Python 3.10 -Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39673] Map errno==ETIME to TimeoutError

[Zackery Spytz]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39673] Map errno==ETIME to TimeoutError

[Eric V. Smith]

Change by Eric V. Smith :


--
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39673] Map errno==ETIME to TimeoutError

[Eric V. Smith]

Change by Eric V. Smith :


--
title: TimeoutError -> Map errno==ETIME to TimeoutError
type: behavior -> enhancement

___
Python tracker 
<https://bugs.python.org/issue39673>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Juliette Monsel]

Change by Juliette Monsel :


--
nosy: +j-4321-i

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jose Salvatierra]

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 worked fine 
until Python 3.7, because the return value of `.map` is something that you can 
pass to `.map` as kw and it'll process it fine.

The return value of `.map` in Python 3.7 is something like this, for the 
`TCombobox`:

```
: {'focusfill': [('readonly', 'focus', 'SystemHighlight')], 
'foreground': [('disabled', 'SystemGrayText'), ('readonly', 'focus', 
'SystemHighlightText')], 'selectforeground': [('!focus', 'SystemWindowText')], 
'selectbackground': [('!focus', 'SystemWindow')]}
```

Which is as you'd expect (and the docs say): a dictionary of properties to 
lists, where each list can contain multiple tuples describing the required 
state and final value of the property.

However in Python 3.8, the value returned by `.map` is this:

```
: {'focusfill': ['readonly focus', 'SystemHighlight'], 
'foreground': ['disabled', 'SystemGrayText', 'readonly focus', 
'SystemHighlightText'], 'selectforeground': ['!focus', 'SystemWindowText'], 
'selectbackground': ['!focus', 'SystemWindow']}
```

The tuples are missing. This then causes a number of problems downstream, such 
as the final property values being split into the constituent letters instead 
of the values within each tuple.

--
components: Tkinter, Windows
messages: 355818
nosy: jslvtr, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Changes to tkinter result in (unexpected) widget map call return changes 
wrt. 3.7
type: behavior
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue38661>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 data set, 
of less than 10 items. We don't want to make Python smaller for operations on 5 
items for example.

The idea which remains open is the idea of adding a "slot" for length hint in 
PyTypeObject. But I would suggest to open a separated issue to explore this 
idea.

Slots allows to use C functions at raw speed and so reduce the cost of getting 
the length hint.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nicholas Musolino]

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 a length hint (or length) function is not 
available, versus a case in which the `__length_hint__()` method of the 
user-supplied iterable raises an exception.

That is, the new PR propagates exceptions (other than TypeError, per PEP 424) 
raised in the `__length_hint__()` functions of the user-supplied iterators.

I've read the comments in this issue, and the notes in `test_iterlen.py`:

> [Other] iterators [...], such as enumerate and the other itertools,
> are not length transparent because they have no way to distinguish between
> iterables that report static length and iterators whose length changes with
> each call (i.e. the difference between enumerate('abc') and
> enumerate(iter('abc')).

Can anyone provide a concrete example that illustrates the inherent 
difficulties of computing a length hint for `map`?  

In ad-hoc testing, the current PR handles situations listed there, and I 
haven't come across some fundamental show-stopper problem.

There are two limitations to the current PR:

1.  The case where a single iterator is supplied as multiple arguments to 
`map`, as pointed out by MSeifert:  
it = iter([1,2,3,4])
    map_it = map(f, it, it)  
2.  When a user-supplied `__length_hint__()` method returns a non-integer, it 
results in a TypeError in an *inner* evaluation of `PyObject_LengthHint()` (per 
PEP 424).  When this exception reaches an *outer* evaluation of 
`PyObject_LengthHint()`, it is cleared (per PEP 424), and leads to 
operator.length_hint's default value being returned.

If we consider issue 2 to be incorrect,  I think I could fix it by raising 
RuntimeError from the original TypeError, or by somewhat invasive refactoring 
of `PyObject_LengthHint()` (which I do not recommend).

--
nosy: +nmusolino

___
Python tracker 
<https://bugs.python.org/issue26828>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37435] builtin map iterator should provide __length_hint__

[Nicholas Musolino]

Change by Nicholas Musolino :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nicholas Musolino]

Change by Nicholas Musolino :


--
pull_requests: +14249
pull_request: https://github.com/python/cpython/pull/14432

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37435] builtin map iterator should provide __length_hint__

[Nicholas Musolino]

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 the original issue?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37435] builtin map iterator should provide __length_hint__

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This is a duplicate of issue26828.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37435] builtin map iterator should provide __length_hint__

[Nicholas Musolino]

Change by Nicholas Musolino :


--
keywords: +patch
pull_requests: +14248
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14432

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37435] builtin map iterator should provide __length_hint__

[Nicholas Musolino]

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 by 
`map` should provide a length hint.  

I suggest the following behavior:  when all the iterator arguments provide a 
valid length hint, the map iterator should return the minimum value among all 
length hint values, because it stops upon exhaustion of the shortest input 
iterator.

If any user-supplied iterator does *not* provide a length hint according to the 
PEP 424 protocol, the map iterator should return the `NotImplemented` 
singleton, in accordance with the protocol.

When the evaluation of `__length_hint__()` for a user-supplied iterator raises 
an exception, the exception should be propagated by the map iterator's 
`__length_hint__()` method.

--
components: Interpreter Core
messages: 346772
nosy: nmusolino
priority: normal
severity: normal
status: open
title: builtin map iterator should provide __length_hint__
type: enhancement

___
Python tracker 
<https://bugs.python.org/issue37435>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36923] Implemented __str__ for zip and map objects

[Serhiy Storchaka]

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 your 
proposition exhausts it.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36923] Implemented __str__ for zip and map objects

[SilentGhost]

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: +SilentGhost
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36923] Implemented __str__ for zip and map objects

[Augustin PROLONGEAU]

New submission from Augustin PROLONGEAU :

I think this would help development a lot.
Below an example of how i would see the function written for zip:

def __str__(self):
return str((*self,))

# And for __repr__ function
def __repr__(self):
return f'zip{str(self)}'

--
messages: 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/issue36923>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Josh Rosenberg]

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 psubmits each of which performs a single psubmit of its own 
would logically involve 1 + #CPUs + #CPU**2 total processes, without the user 
ever explicitly asking for them.

Especially in a fork-based context, this could easily trigger the Linux 
OOM-killer if the parent process is of even moderate size, since a four core 
system with a 1 GB parent process would suddenly be asking for up to 21 GB of 
memory. Most of that is only potentially used, given COW behavior, but the OOM 
killer assumes COW memory will eventually be copied (and it's largely right 
about that for CPython given the cyclic garbage collector's twiddling of 
reference counts), so it's hardly relevant if 21 GB is actually used; the 
OOM-killer doesn't care, and will murder the process anyway.

The alternative would be having the default process executor shared with the 
child processes, but that just means process usage would be subject to the same 
deadlocks as in Brian's threaded case.

This also defeats the purpose of the Executor model; Java, which pioneered it 
to my knowledge, intentionally required you to create the executor up front 
(typically in a single global location) because the goal is to allow you to 
change your program-wide parallelism model by changing a single line (the 
definition of the executor), with all uses of the executor remaining unchanged. 
Making a bunch of global functions implicitly tied to different 
executors/executor models means the parallelism is no longer centrally defined, 
so switching models means changes all over the code base (in Python, that's 
often unavoidable due to constraints involving pickling and data sharing, but 
there is no need to make it worse).

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Brian Quinlan]

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 deadlock if no more free threads.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[ROGER GRAYDON CHRISTMAN]

On Sat, Sep 22, 2018, Victor (vhnguy...@yahoo.com) wrote 
Let me use a different input args and display them below.  Basically, I am
hoping to add up all elements of each nested list.  So at first it should start
with [1,11,111] ==> 1+11+111 = 123.  But instead, it appears to take the 1st
element 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 second argument, it will visit eachelement
of that single list (which in this case are the sublists you want).
But that * is replacing the single list with the list contents as separate
arguments,so you are literally telling map to visit all three sublists in
parallel,and it does exactly what you told it to.
The * and ** prefixes really should be avoided as much as possible,unless you
know exactly what you are getting out of them.
Roger ChristmanPennsylvania State University


-- 
https://mail.python.org/mailman/listinfo/python-list