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

[xavieryao]

BPO	46621
Nosy	@rhettinger, @vedgar, @xavieryao

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-02-03.04:46:26.741>
labels = ['type-bug']
title = 'Should map(function, iterable, ...) replace StopIteration with RuntimeError?'
updated_at = <Date 2022-02-03.17:00:32.133>
user = 'https://github.com/xavieryao'

bugs.python.org fields:

activity = <Date 2022-02-03.17:00:32.133>
actor = 'veky'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2022-02-03.04:46:26.741>
creator = 'xavieryao'
dependencies = []
files = []
hgrepos = []
issue_num = 46621
keywords = []
message_count = 3.0
messages = ['412419', '412420', '412449']
nosy_count = 3.0
nosy_names = ['rhettinger', 'veky', 'xavieryao']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46621'
versions = []

[xavieryao]

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/

[rhettinger]

-1 for being a breaking change, for addressing a minor issue that rarely arises in real life, and for being a slippery slope.

[vedgar]

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.