Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-None return value from generator should throw RuntimeError #127306

Open
jvm-pangea opened this issue Nov 26, 2024 · 5 comments
Open

Non-None return value from generator should throw RuntimeError #127306

jvm-pangea opened this issue Nov 26, 2024 · 5 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) pending The issue will be closed if no feedback is provided type-feature A feature request or enhancement

Comments

@jvm-pangea
Copy link

jvm-pangea commented Nov 26, 2024

Bug report

Bug description:

def y1(*args):
    return args

def y2(*args):
    return args
    yield 3

print("y1: " + str(list(y1(1, 2, 3, 4))))
print("y2: " + str(list(y2(1, 2, 3, 4))))

While the yield in y2 is unreachable (this happened to me while re-writing a function and leaving what I thought was dead code at the end), y2 is considered a Generator, and iterating over it produces an immediate StopIteration error with args as the argument, which manifests as an empty iterator.

I can't imagine a good reason to create a StopIteration exception with a non-None argument. With a None argument, this signals the basic case where a Generator is returning an empty iterator.

Consider throwing RuntimeError when StopIteration is raised with a non-None valued error when calling next to prevent this confusing behaviour.

CPython versions tested on:

3.10

Operating systems tested on:

macOS

@jvm-pangea jvm-pangea added the type-bug An unexpected behavior, bug, or error label Nov 26, 2024
@brianschubert
Copy link
Contributor

Hi jvm-pangea, using return in generators is an intentional feature. You can see PEP 380 for some of the original motivation and use cases.

@nineteendo
Copy link
Contributor

This feels like a problem for a linter to flag.

@jvm-pangea
Copy link
Author

PEP 380 will take some time for me to grok, it's pretty dense.

Is there no way to know when executing the byte-code that you're handling a StopIteration in the context of a yield from (where it is expected) vs. in a naked generator where the non-None valued exception would clearly be problematic?

@picnixz
Copy link
Contributor

picnixz commented Nov 27, 2024

I agree that this is more a linter issue rather than a core issue. If you want to change the current behaviour a PEP is likely needed or at least a d.p.o thread (https://discuss.python.org/c/ideas/6).

@picnixz picnixz added pending The issue will be closed if no feedback is provided type-feature A feature request or enhancement interpreter-core (Objects, Python, Grammar, and Parser dirs) and removed type-bug An unexpected behavior, bug, or error labels Nov 27, 2024
@jvm-pangea
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) pending The issue will be closed if no feedback is provided type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

4 participants