GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||
GeezerVison is showing github.com — bpo-28331: fix "CPython implementation detail:" label is removed when content is translated. by methane · Pull Request #195 · python/cpython Conversation… content is translated.
berkerpeksag
requested changes
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, I'm strongly against introducing yet another hack for a pretty small use case.
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactions
Member
Author
All reactions
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page.
Member
Author
All reactions
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page.
vstinner
approved these changes
|
There was an error while loading. Please reload this page.
|
@berkerpeksag
This pull request changes two thing:
1. Fix "CPython implementation detail:" label disappears when it's body is translated.
This must be fixed, otherwise people think it's Python's guarantee.
(Imagine that "CPython implementation detail: This is the address of the object in memory." becomes "This is the address of the object in memory.")
And this change make the implementation same to version(added|changed) directive in Sphinx. So I think it's proper implementation rather than hack. I strongly want to fix this in upstream.
2. Make "CPython implementation detail:" label translatable.
Untranslatable label is minor problem compared to (1), and this change uses hack (dummy.html to expose label text to pot file via {% trans %} tag).
If you still strong -1 about adding hack, I'll remove dummy.html. Downstream translation project can add dummy.html by themselves, without touching python source.
But I feel "add this in downstream project" is also hack.
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I think matching the implementation of the imp-detail directive with the other custom directives is a good idea -- I don't have an objection to that part of the PR. However, I'm still -1 on adding a dummy HTML. Customizing the tools of an upstream project is a very common practice in open source world. Downstream projects are doing a lot of different things with Python and this doesn't mean that all these hacks should go into upstream (we've rejected most of them in the past) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I started a thread on python-dev to get an official go for the translated
doc:
https://mail.python.org/pipermail/python-dev/2017-February/147416.html
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I saw most replies on the ML thread is positive. Now I think this change is safe enough to merge, and small enough to maintain. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Since translation will be focus on latest stable release, I removed "needs backport to (2.7|3.5)" labels. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
…d. (pythonGH-195) (cherry picked from commit c351ce6)
…r coroutines (python#195) Silently ignore attempts to close a running generator, coroutine or asynchronous generator. This avoids spurious error messages, if such an object is deallocated as part of a paused, restorable tasklet.
Stackless can now pickle coroutine_wrapper objects.
…r coroutines (python#195) Silently ignore attempts to close a running generator, coroutine or asynchronous generator. This avoids spurious error messages, if such an object is deallocated as part of a paused, restorable tasklet. (cherry picked from commit 905d0ef)
Investigation artifact per supervisor 15:14:01Z (in-tree evidence prevents next-session/future readers from re-discovering). Closes the 'pre-existing structural causal absence' dismissal pattern that BLME b2 / kwnames / preloader_ ABBA reports applied to gen_simple's 0.73x ratio (pythia python#195 catch). docs/benchmarks/gen_simple_investigation_2026-04-27.md 3-config focused timing at ABBA-calibrated n_iter=8,700,000: Vanilla CPython 3.12 505 ms 1.00x Phoenix interpreter (no auto) 472 ms 0.94x (FASTER than vanilla) Phoenix + cinderjit.auto 670 ms 1.33x (SLOWER than vanilla, 1.42x SLOWER than Phoenix's interpreter) The 0.73x ratio is the Phoenix JIT generator-compilation cost itself — not pre-existing baseline noise. Phoenix's interpreter beats vanilla on this workload by 6%; only the JIT path regresses. The 4 observer commits (BLME b2, kwnames, preloader_, push-59 baseline) don't touch generator codegen so they couldn't have introduced the regression — but the regression IS Phoenix-introduced, just upstream of those probes. Per feedback_assume_phoenix_regression.md (Alex 2026-04-24): every regression presumed Phoenix-introduced; per feedback_falsifier_convergent_negative.md: convergent-negative delta needs investigated-no-quick-fix framing, not pre-existing escape. Mechanism (hypothesis): Phoenix cinderjit.auto JIT-compiles the inner gen() closure once the call-count crosses the 1000-call auto-compile threshold. The JIT'd generator runs slower per-yield than the interpreter on this workload — likely candidates: per-yield codegen overhead in Phoenix's JIT generator path, or auto-compile threshold + counting overhead amortized across too few iterations. Not yet root-caused at the Phoenix-source layer. Next-step options (deferred to next-session fix-class workstream per supervisor 15:14:01Z): (a) cinderx_dev oracle bisect (Tier-1 falsifier per Alex's policy — recommended first step per theologian 15:13:57Z) (b) Profile + perf-record the JIT'd gen() execution (c) Park as 'investigated-no-quick-fix' if (a)+(b) show architectural cost with no localizable hotspot ABBA-report convention going forward (per supervisor 15:14:01Z cascade): gen_simple is no longer 'pre-existing'; new framing is 'Phoenix JIT generator-compilation regression, root-cause class identified (this artifact), bisect queued for next-session'. Until the bisect lands, this artifact is the workstream-tag the gatekeeper >5% BLOCK rule (15:12:00Z) accepts as the evidence-class root-cause citation distinguishing the regression from a generic pre-existing dismissal. Doc-only commit. No JIT/build/codegen surface; trivial-push exemption.
Stable 0.70-0.76x vs vanilla CPython on bench_gen_simple across 11+ days, 6+ commit surfaces, 9 logged ABBA runs since 2026-04-16. Not a recent regression. Mechanism candidate: 87,000 short-lived generators per rep × per- generator-creation JIT-prologue/epilogue cost. Confirmed cinderjit.auto IS the cost driver (Phoenix JIT_OFF 491ms vs JIT_ON 633ms vs vanilla 476ms; testkeeper /tmp/gen_simple_match_harness.py 2026-04-27T15:14:16Z). Doc supersedes the prior dismissal framing 'pre-existing structural causal absence' (caught by pythia python#195 + medic motivated-reasoning warning). Replacement framing: 'Phoenix-stable known-cost, fix-class workstream queued post-terminal-goal'. Anti-pattern guard + threshold signal preserved (drops below 0.70x or rises above 0.76x = NEW signal, investigate). Status: PARKED behind pure-C JIT terminal-goal completion per Alex priority order. Resumption gate enumerates 5-step procedure when fix-class work opens. Per supervisor 2026-04-27T15:15:20Z disposition (a) following testkeeper investigation 15:14:16Z + theologian patch-shape APPROVE 15:17:13Z.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.