GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Avoid creating a StopIteration instance for monitoring · Issue #118692 · python/cpython

Avoid creating a StopIteration instance for monitoring #118692

New issue
Copy link
New issue
Copy link
Closed
#119216
Closed
Avoid creating a StopIteration instance for monitoring#118692
#119216
Copy link
Assignees
iritkatriel
Labels
3.13only security fixesonly security fixestype-featureA feature request or enhancementA feature request or enhancement

Description

@scoder
scoder
opened on May 7, 2024
Issue body actions

Feature or enhancement

Proposal:

A new C-API for injecting monitoring events was discussed in #111997 and implemented for Py3.13 in #116413

A remaining issue is that signalling "STOP_ITERATION" events requires a StopIteration exception instance, whereas generators usually try to avoid creating one during termination to increase their performance.

I think it would be best if CPython's monitoring infrastructure created a StopIteration instance automatically when it detects that it needs to notify about it without having one. It's in the best position to detect whether it really needs an exception instance or not. Event sources shouldn't be forced to a) figure that out themselves or b) create an instance just for it to be thrown away.

CPython already creates an exception instance for submitting a monitoring event for a generator, but does so unconditionally. It would also benefit from not having to generate one unless it's really needed for signalling.

cpython/Python/bytecodes.c

Lines 289 to 317 in 5248596

macro(END_FOR) = POP_TOP;
tier1 inst(INSTRUMENTED_END_FOR, (receiver, value -- receiver)) {
/* Need to create a fake StopIteration error here,
* to conform to PEP 380 */
if (PyGen_Check(receiver)) {
PyErr_SetObject(PyExc_StopIteration, value);
if (monitor_stop_iteration(tstate, frame, this_instr)) {
ERROR_NO_POP();
}
PyErr_SetRaisedException(NULL);
}
DECREF_INPUTS();
}
pure inst(END_SEND, (receiver, value -- value)) {
Py_DECREF(receiver);
}
tier1 inst(INSTRUMENTED_END_SEND, (receiver, value -- value)) {
if (PyGen_Check(receiver) || PyCoro_CheckExact(receiver)) {
PyErr_SetObject(PyExc_StopIteration, value);
if (monitor_stop_iteration(tstate, frame, this_instr)) {
ERROR_NO_POP();
}
PyErr_SetRaisedException(NULL);
}
Py_DECREF(receiver);
}

Basically, we should move the existing code from the byte code handlers all the way to the other side into the notification mechanism.

In order to report the correct StopIteration value, the event creation function should accept an object value directly, and create a StopIteration instance for that value only if it ends up signalling it to listeners.

We might allow passing the value NULL (as opposed to the object value None) to make the machinery look up an actually existing currently raised StopIteration instance. Alternatively, passing a StopIteration instance as value is probably also a reasonably clear indication for an instance being available already. We may also consider adding two event creation functions, one with a bare stop value and one with a readily created StopIteration instance.

This ticket proposes a usability/performance enhancement to a newly added feature in Py3.13, and thus does not fall under the "beta-1" release end of new features.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

#116413 (comment)

Linked PRs

  • gh-118692: Avoid creating unnecessary StopIteration instances for monitoring #119216
  • [3.13] gh-118692: Avoid creating unnecessary StopIteration instances for monitoring (GH-119216) #119497

Activity

  1. scoder
    added
    type-featureA feature request or enhancementA feature request or enhancement
    3.13only security fixesonly security fixes
    on May 7, 2024
  2. scoder commented on May 7, 2024

    @scoder
    scoder
    on May 7, 2024
    ContributorAuthor
    More actions

    @iritkatriel @markshannon @encukou

  3. iritkatriel
    self-assigned this
    on May 7, 2024
  4. iritkatriel
    added a commit that references this issue on May 20, 2024

    pythongh-118692: Avoid creating unnecessary StopIteration instances f…

    2e774c2
  5. iritkatriel
    closed this as completedin #119216on May 21, 2024
  6. iritkatriel
    added a commit that references this issue on May 21, 2024

    gh-118692: Avoid creating unnecessary StopIteration instances for mon…

    6e9863d
  7. miss-islington
    added a commit that references this issue on May 24, 2024

    pythongh-118692: Avoid creating unnecessary StopIteration instances f…

    06943e2
  8. iritkatriel
    added a commit that references this issue on May 24, 2024

    [3.13] gh-118692: Avoid creating unnecessary StopIteration instances …

    c864efb
  9. estyxx
    added a commit that references this issue on Jul 17, 2024

    pythongh-118692: Avoid creating unnecessary StopIteration instances f…

    4eb906e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

  • @iritkatriel
    iritkatriel

Labels

3.13only security fixesonly security fixestype-featureA feature request or enhancementA feature request or enhancement

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402503 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.