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 — gh-149202: Fix frame pointer unwinding on ppc64le and armv7/clang by encukou · Pull Request #149409 · python/cpython

Conversation

@encukou

@encukou encukou commented May 5, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Member

This is based on @pablogsal's #149362; I want to run CI without pushing to his branch.

[edit] This PR now adds support for ppc64le and for clang on 32-bit ARM.

  • Issue: Implement PEP 831 – Frame Pointers Everywhere: Enabling System-Level Observability for Python #149202

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
pablogsal and others added 5 commits May 4, 2026 20:14
@pablogsal
pythongh-149202: Fix frame pointer unwinding on s390x and ARM
c68855d 
-fno-omit-frame-pointer is not enough to make every target walkable by the simple manual frame pointer unwinder.

The helper used by test_frame_pointer_unwind used to assume the frame pointer named a two-word record where fp[0] was the previous frame pointer and fp[1] was the return address. That is only the generic layout used by some targets. This patch keeps that default, but moves the slots behind named offsets so architecture-specific layouts can describe where the backchain and return address really live.

On s390x, GCC and Clang do not emit a usable backchain unless -mbackchain is also enabled. Without it, the unwinder stops at the current C frame and the test reports no Python frames. Once backchains are present, the helper must also stop at the current thread's known C stack bounds; otherwise it can follow the final backchain far enough to dereference an invalid frame and segfault. For Linux s390x backchain frames, the documented z/Architecture stack-frame layout saves r14, the return-address register, at byte offset 112 from the frame pointer, so read the return address from that named slot instead of fp[1].

The 112-byte offset comes from Linux's s390 debugging documentation: its Stack Frame Layout table shows z/Architecture backchain frames with the backchain at offset 0 and saved r14 of the caller function at offset 112: https://www.kernel.org/doc/html/v5.3/s390/debugging390.html#stack-frame-layout

This helper remains scoped to Linux s390x backchain frames. GNU SFrame's s390x notes state that the s390x ELF ABI does not generally mandate where RA and FP are saved, or whether they are saved at all: https://sourceware.org/binutils/docs/sframe-spec.html#s390x

On 32-bit ARM, GCC defaults to Thumb mode on common armhf toolchains. The Thumb prologue keeps the saved frame pointer and link register at offsets that depend on the generated frame, which breaks the fp[0]/fp[1] walk used by the helper. Use -marm when it is supported for frame-pointer builds, and teach the helper the GCC ARM-mode slots where the previous frame pointer is at fp[-1] and the saved LR return address is at fp[0].
@encukou
Advertise frame pointer support via _Py_WITH_FRAME_POINTERS
ad2c814
@encukou
Use -mbackchain only on s390x
242a58e
@encukou
Adjust comment
9b74182
@encukou
Merge in the main branch
efb829e
@encukou
encukou requested review from AA-Turner, corona10, emmatyping and erlend-aasland as code owners May 5, 2026 11:47
@bedevere-app bedevere-app Bot mentioned this pull request May 5, 2026
Implement PEP 831 – Frame Pointers Everywhere: Enabling System-Level Observability for Python #149202
Closed
@bedevere-app bedevere-app Bot added the awaiting core review label May 5, 2026
@read-the-docs-community

read-the-docs-community Bot commented May 5, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown

Documentation build overview

📚 cpython-previews | 🛠️ Build #32565506 | 📁 Comparing b7cb2b3 against main (f6d16a0)

  🔍 Preview build  

21 files changed · ± 21 modified

± Modified

  • c-api/exceptions.html
  • deprecations/index.html
  • deprecations/pending-removal-in-3.17.html
  • deprecations/pending-removal-in-3.19.html
  • howto/perf_profiling.html
  • library/datatypes.html
  • library/difflib.html
  • library/functions.html
  • library/imaplib.html
  • library/pprint.html
  • and 11 more...
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou
Regen configure
a612c88
@encukou encukou added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label May 5, 2026
@bedevere-bot

bedevere-bot commented May 5, 2026

Copy link
Copy Markdown

🤖 New build scheduled with the buildbot fleet by @encukou for commit efb829e 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F149409%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label May 5, 2026
@encukou
Merge in the main branch
955261c
@encukou

encukou commented May 5, 2026

Copy link
Copy Markdown
Member Author

!buildbot ARM
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@bedevere-bot

bedevere-bot commented May 5, 2026

Copy link
Copy Markdown

🤖 New build scheduled with the buildbot fleet by @encukou for commit 955261c 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F149409%2Fmerge

The command will test the builders whose names match following regular expression: ARM

The builders matched are:

  • ARM64 macOS PR
  • ARM64 Raspbian Debug PR
  • ARM64 Windows PR
  • ARM64 Raspbian PR
  • ARM64 MacOS M1 Refleaks NoGIL PR
  • ARM Raspbian PR
  • iOS ARM64 Simulator PR
  • ARM64 MacOS M1 NoGIL PR
  • ARM64 Windows Non-Debug PR
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou

encukou commented May 5, 2026

Copy link
Copy Markdown
Member Author

!buildbot S390x
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@bedevere-bot

bedevere-bot commented May 5, 2026

Copy link
Copy Markdown

🤖 New build scheduled with the buildbot fleet by @encukou for commit 955261c 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F149409%2Fmerge

The command will test the builders whose names match following regular expression: S390x

The builders matched are:

  • s390x Fedora Rawhide NoGIL refleaks PR
  • s390x RHEL8 LTO + PGO PR
  • s390x Fedora Rawhide PR
  • s390x RHEL9 PR
  • s390x RHEL8 LTO PR
  • s390x RHEL9 Refleaks PR
  • s390x Fedora Rawhide NoGIL PR
  • s390x Fedora Stable PR
  • s390x Fedora Rawhide Clang PR
  • s390x Fedora Stable Clang Installed PR
  • s390x RHEL9 LTO PR
  • s390x Fedora Rawhide Refleaks PR
  • s390x Fedora Stable LTO PR
  • s390x Fedora Rawhide LTO + PGO PR
  • s390x RHEL8 PR
  • s390x Fedora Stable LTO + PGO PR
  • s390x RHEL8 Refleaks PR
  • s390x Fedora Stable Refleaks PR
  • s390x Fedora Stable Clang PR
  • s390x RHEL9 LTO + PGO PR
  • s390x Fedora Rawhide Clang Installed PR
  • s390x Fedora Rawhide LTO PR
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou encukou mentioned this pull request May 5, 2026
gh-149202: Fix frame pointer unwinding on s390x and ARM #149362
Merged
@stratakis

stratakis commented May 6, 2026

Copy link
Copy Markdown
Contributor

Just read the PEP today, so I'll gently nudge for an extra fix here, or maybe I could send another PR :)

ppc64le doesn't need any frame pointer compiler flags, so I'd exclude it entirely through configure.

The power abi specification requires that compilers maintain a back chain by default, so unwinding already works without a dedicated frame pointer. Adding however -fno-omit-frame-pointer forces the compiler to reserve r31 for it adding extra overhead with no benefits.

Also following up on Diego's comment, the current unwinding model here won't work for ppc64le (stack frame layout is on page 34 of the ABI spec pdf). The LR is saved in the caller's frame (SP+16), not the current frame, so frame_pointer[RETURN_OFFSET] can't reach it.

I can provide access to a power buildbot for testing it out or try to come up with a solution myself.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou

encukou commented May 6, 2026

Copy link
Copy Markdown
Member Author

@diegorusso, does this look good to you?
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou
Merge in the main branch
92ee35e
vstinner
vstinner reviewed May 6, 2026
View reviewed changes

@vstinner vstinner left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested manually the change on s390x: test_frame_pointer_unwind fails on the main branch, and pass with this change: the PR works as expected.

Only -mbackchain is used (-fno-omit-frame-pointer is not used):

$ grep backchain Makefile
BASECFLAGS=	-mbackchain  -fno-strict-overflow -Wsign-compare

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread Doc/howto/perf_profiling.rst Outdated
toolchains, CPython builds itself with ``-fno-omit-frame-pointer`` and, when
available, ``-mno-omit-leaf-frame-pointer`` by default. These flags allow
available, ``-mno-omit-leaf-frame-pointer`` by default. On 32-bit ARM,
CPython also adds ``-marm`` when supported. On s390 platforms, CPython also

@vstinner vstinner May 6, 2026

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s390 refers to the old 32-bit platform which is no longer in use. You should write s390x to refer to the current 64-bit Linux platform. Same remark for the whole PR.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread configure.ac Resolved

Uh oh!

There was an error while loading. Please reload this page.
Comment thread Misc/NEWS.d/next/Core_and_Builtins/2026-04-05-16-10-00.gh-issue-149202.W8sQeR.rst Outdated
``-mno-omit-leaf-frame-pointer``, ``-marm`` on 32-bit ARM, and ``-mbackchain``
on s390 platforms when the compiler supports them, so profilers and debuggers
can unwind native interpreter frames more reliably. Users can pass
``--without-frame-pointers`` to opt out.

@vstinner vstinner May 6, 2026

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
``--without-frame-pointers`` to opt out.
:option:`--without-frame-pointers` to ``./configure`` to opt out.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread Doc/whatsnew/3.15.rst
.. _whatsnew315-frame-pointers:

* CPython is now built with frame pointers enabled by default
(:pep:`831`). Pass :option:`--without-frame-pointers` to opt out.

@vstinner vstinner May 6, 2026

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(:pep:`831`). Pass :option:`--without-frame-pointers` to opt out.
(:pep:`831`). Pass :option:`--without-frame-pointers` to ``./configure`` to opt out.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread Doc/using/configure.rst Outdated
By default, the build appends ``-fno-omit-frame-pointer``,
``-mno-omit-leaf-frame-pointer`` when the compiler supports it,
``-marm`` on 32-bit ARM when supported, and ``-mbackchain`` on s390
platforms when supported, to ``BASECFLAGS`` so

@vstinner vstinner May 6, 2026

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be useful to explain that -fno-omit-frame-pointer and -mno-omit-leaf-frame-pointer are not used (and should not be used) on s390x, only -mbackchain is used. Same remark for other places documenting these compiler flags.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@encukou
Adjust docs & comment
02617af
@encukou

encukou commented May 6, 2026

Copy link
Copy Markdown
Member Author

Thanks for the review!
I pushed to Pablo's original PR: github.com//pull/149362. I'll close this one.
hugovk reacted with rocket emoji
All reactions
  • 🚀 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou encukou closed this May 6, 2026
@encukou
Account for ppc64le
cfc9b62
encukou
encukou commented May 6, 2026
View reviewed changes
Comment thread Modules/_testinternalcapi.c
# define FRAME_POINTER_NEXT_OFFSET 0
# define FRAME_POINTER_RETURN_OFFSET \
(S390X_FRAME_RETURN_ADDRESS_OFFSET / (Py_ssize_t)sizeof(uintptr_t))
#elif defined(__powerpc64__) || defined(__ppc64__)

@encukou encukou May 6, 2026

Copy link
Copy Markdown
Member Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vstinner as the powerpc expert: Are these the right macros to detect ppc64le?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions

@vstinner vstinner May 6, 2026

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#if defined(__powerpc64__) || defined(__ppc64__) looks to good to me according to existing CPython code. __powerpc64__ macro is defined on Linux. The __ppc64__ macro is maybe needed on macOS or Windows, I'm not sure, but it's good to check for the two macros :-)

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions

@encukou encukou May 6, 2026

Copy link
Copy Markdown
Member Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the Linux stack layout might not apply to Mac... but then again, the last ppc Mac came out 20 years ago.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@encukou

encukou commented May 6, 2026

Copy link
Copy Markdown
Member Author

!buildbot PPC64LE
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@bedevere-bot

bedevere-bot commented May 6, 2026

Copy link
Copy Markdown

🤖 New build scheduled with the buildbot fleet by @encukou for commit 4ad01d6 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F149409%2Fmerge

The command will test the builders whose names match following regular expression: PPC64LE

The builders matched are:

  • PPC64LE Fedora Rawhide Clang PR
  • PPC64LE RHEL8 Refleaks PR
  • PPC64LE RHEL8 LTO + PGO PR
  • PPC64LE Fedora Stable Clang PR
  • PPC64LE Fedora Rawhide NoGIL refleaks PR
  • PPC64LE Fedora Rawhide PR
  • PPC64LE CentOS9 LTO PR
  • PPC64LE Fedora Rawhide Clang Installed PR
  • PPC64LE Fedora Stable Refleaks PR
  • PPC64LE Fedora Rawhide LTO PR
  • PPC64LE Fedora Stable PR
  • PPC64LE Fedora Stable LTO + PGO PR
  • PPC64LE CentOS9 LTO + PGO PR
  • PPC64LE Fedora Stable LTO PR
  • PPC64LE Fedora Rawhide NoGIL PR
  • PPC64LE Fedora Rawhide Refleaks PR
  • PPC64LE Fedora Stable Clang Installed PR
  • PPC64LE Fedora Rawhide LTO + PGO PR
  • PPC64LE CentOS9 PR
  • PPC64LE RHEL8 LTO PR
  • PPC64LE RHEL8 PR
  • PPC64LE CentOS9 Refleaks PR
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@vstinner

vstinner commented May 6, 2026

Copy link
Copy Markdown
Member

Let me reopen to run CI for ppc64le support.

There is also the PR gh-149362. I don't understand why PR should be used. If you only want to develop/debug in this PR, maybe mark it as a draft?
encukou reacted with thumbs up emoji
All reactions
  • 👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou
Also use -mno-thumb for 32-bit ARM
1db3418
@encukou
encukou marked this pull request as draft May 6, 2026 14:15
@bedevere-app bedevere-app Bot removed the awaiting core review label May 6, 2026
@encukou encukou changed the title gh-149202: Fix frame pointer unwinding on s390x and ARM gh-149202: Fix frame pointer unwinding on ppc64le and armv7/clang May 6, 2026
@encukou
Merge in the main branch
b7cb2b3
@encukou encukou added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label May 6, 2026
@bedevere-bot

bedevere-bot commented May 6, 2026

Copy link
Copy Markdown

🤖 New build scheduled with the buildbot fleet by @encukou for commit b7cb2b3 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F149409%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label May 6, 2026
@encukou encukou added the skip news label May 6, 2026
@encukou
encukou marked this pull request as ready for review May 6, 2026 15:18
@bedevere-app bedevere-app Bot added the awaiting core review label May 6, 2026
vstinner
vstinner approved these changes May 6, 2026
View reviewed changes

@vstinner vstinner left a comment

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

I tested this change manually on Linux ppc64le: test_frame_pointer_unwind does pass on Python built with ./configure --with-pydebug (gcc -Og) and on Python built with ./configure (gcc -O3).

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
encukou reacted with heart emoji
All reactions
  • ❤️ 1 reaction
@bedevere-app bedevere-app Bot added awaiting merge and removed awaiting core review labels May 6, 2026
@encukou

encukou commented May 6, 2026

Copy link
Copy Markdown
Member Author

ARM Raspbian still fails the gnu_backtrace test; manual unwinding seems fine there.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@diegorusso

diegorusso commented May 6, 2026

Copy link
Copy Markdown
Contributor

ARM Raspbian still fails the gnu_backtrace test; manual unwinding seems fine there.

The GNU backtrace failure is independent from the FP. Backtrace uses eh_frame information and on Arm (32bit) we should build Python with -funwind-tables.
I'm still investigating my theory but it is very likely this to be the case. If it is, it would be safe just to skip the backtrace tests on Arm 32-bit.

https://stackoverflow.com/questions/24700150/on-raspberry-pi-backtrace-returns-0-frames
vstinner reacted with eyes emoji
All reactions
  • 👀 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@diegorusso

diegorusso commented May 6, 2026

Copy link
Copy Markdown
Contributor

ARM Raspbian still fails the gnu_backtrace test; manual unwinding seems fine there.

The GNU backtrace failure is independent from the FP. Backtrace uses eh_frame information and on Arm (32bit) we should build Python with -funwind-tables. I'm still investigating my theory but it is very likely this to be the case. If it is, it would be safe just to skip the backtrace tests on Arm 32-bit.

https://stackoverflow.com/questions/24700150/on-raspberry-pi-backtrace-returns-0-frames

I confirm that this is the case. I'm going to raise a new PR to skip the GNU backtrace test on Arm Raspbian.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pablogsal

pablogsal commented May 6, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Member

Wait this doesn't check out Python should be build with eh_frame in all architectures no? Why is this deactivated by default on arm 32 bit?! How does gdb work there?
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@encukou encukou mentioned this pull request May 7, 2026
GH-126910: Add GNU backtrace support for unwinding JIT frames #149104
Merged
@encukou
encukou merged commit 612140e into python:main May 7, 2026
148 of 157 checks passed

Uh oh!

There was an error while loading. Please reload this page.
@bedevere-app bedevere-app Bot removed the awaiting merge label May 7, 2026
@encukou
encukou deleted the gh-149202-2 branch May 7, 2026 08:37
@diegorusso

diegorusso commented May 7, 2026

Copy link
Copy Markdown
Contributor

Wait this doesn't check out Python should be build with eh_frame in all architectures no? Why is this deactivated by default on arm 32 bit?! How does gdb work there?

I had to investigate this a little bit but I'll reply to you in the PR I'm going to create. TL;DR: .eh_frame is not the runtime unwind format on every architecture.

  • AArch64, runtime unwinding uses .eh_frame / .eh_frame_hdr.
  • 32-bit ARM EABI, runtime unwinding uses .ARM.exidx / .ARM.extab.

GDB works on the 32-bit ARM binary because it can read debugger-only .debug_frame from the ELF file.
glibc backtrace() cannot rely on that; it needs runtime unwind tables.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@vstinner vstinner mentioned this pull request May 7, 2026
gh-149202: Don't use -fno-omit-frame-pointer on ppc64le #149485
Merged
@vstinner

vstinner commented May 7, 2026

Copy link
Copy Markdown
Member

@stratakis:

The power abi specification requires that compilers maintain a back chain by default, so unwinding already works without a dedicated frame pointer. Adding however -fno-omit-frame-pointer forces the compiler to reserve r31 for it adding extra overhead with no benefits.

I wrote PR gh-149485 to remove -fno-omit-frame-pointer on ppc64le.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@diegorusso

diegorusso commented May 7, 2026

Copy link
Copy Markdown
Contributor

Wait this doesn't check out Python should be build with eh_frame in all architectures no? Why is this deactivated by default on arm 32 bit?! How does gdb work there?

Raised here: #149493
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@vstinner vstinner vstinner approved these changes
@AA-Turner AA-Turner Awaiting requested review from AA-Turner AA-Turner is a code owner
@erlend-aasland erlend-aasland Awaiting requested review from erlend-aasland erlend-aasland is a code owner
@corona10 corona10 Awaiting requested review from corona10 corona10 is a code owner
@emmatyping emmatyping Awaiting requested review from emmatyping emmatyping is a code owner

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

skip news

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

6 participants

@encukou @bedevere-bot @stratakis @vstinner @diegorusso @pablogsal
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.