[GH-ISSUE #6922] [Feature] Select Python pyc code objects without returning the full report #4239

Closed
opened 2026-10-31 00:47:58 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @gensokyo-dev on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6922

Before submitting

  • Searched open/closed issues and PRs for related PYC proposals.
  • Reviewed contribution scope; this extends static inspection and historical Evidence querying, with no new target execution or mutation.
  • No credentials or private target samples are included.

Area

Evidence, artifacts, or reconstruction; MCP/CLI efficiency.

Current limitation

At main 1a808dd2a239f5259af549de3a40103a03d4c05d, answering “return every code object named parse_args, parse_known_args or _parse_known_args, with source index, qualified name, filename/line, bytecode length/SHA-256 and nested-code references” requires receiving the complete PYC report. The real stdlib argparse pyc contains 194 code objects; only three answer this question.

Executed production stdio MCP discovery and inspection, checked against an independent CPython 3.11.2 marshal walk. The complete reply is 338,090 serialized bytes, including 48,813 estimated text-reply tokens. A one-pass input catalog, question, arguments and reply total 103,725 estimated tokens. Raw transport catalog including output schemas is counted separately, not as model input. These use tiktoken 0.14.0/cl100k_base and a scripted SDK client with the discovered exact toolDefinition/default validator; no model ran.

One fresh-session diagnostic completed in 5.055s wall / 4.675s process-family CPU / 513.2 MiB peak. This is one baseline sample, not a speedup claim. CPython bytecode was read, never executed. Target SHA-256: 6fa55dc31dd55ddb1766369755b5cda156a42cf41193a0ff1de0189bffb4aa51 (113,662 bytes).

Separate actual capability probes confirm that detail: summary is rejected by inspect_python_pyc's input contract, and inspect_analysis_view returns unsupported_target for retained inspect_python_pyc Evidence, including its generic summary view.

Use cases

Inspect selected nested functions/classes or compare selected bytecode identities without consuming unrelated constants/name tables. A compiler-produced small control has duplicate parse_args names; every matching code object must remain independently addressable.

Desired outcome and success criteria

  • Preserve default complete output, caller budgets, byte identity, existing coverage and limitations.
  • Offer optional summary delivery with retained complete Evidence and an existing full-Evidence export/offline path.
  • Extend inspect_analysis_view with a named python-pyc code_objects collection: exact names/indices, field selection and paging; original report index stays scoped to its parent Evidence. Preserve all same-name alternatives, null/omitted values, empty selectors and empty results.
  • Keep nested_code as code-constant references, not a reconstructed runtime call graph. Reuse the owning parsed facts across CLI/MCP; do not reopen the artifact for historical views.
  • Verify real argparse plus small/compiler-produced controls with an independent CPython oracle, schema/client checks and complete-source access. Compare repeated equivalent tasks including discovery, extra calls, elapsed/family CPU/peak memory and labeled token estimates. No time/memory benefit is assumed from fewer output bytes.

Expected interaction with targets

Read existing files/captured data. Existing explicit Evidence exports write analyst-selected output files. No execution, injection, source recovery or modification of the inspected pyc; runtime inspection still requires no Python installation.

Verification available so far

Observed baseline results and independent oracle. Both complete-report workflows (real argparse and the duplicate-name control) passed with verified payload cleanup and no OOM/resource stops under CPUQuota100%, 3 GiB early stop/4 GiB hard cap. The cached prerequisite build had a transient remaining worker at payload exit; its unique scope was subsequently verified inactive and the worker absent. Final whole-scope counters are unavailable. Proposed selected delivery is not implemented yet.

Alternatives considered / possible direction

Client-side filtering receives the full report first. Current analysis views reject this parent operation. Reuse the existing retained-summary/typed-view workflow used for native exports; keep one shared projector and exact named contracts. Avoid a second parser, path cache or separate query tool.

References and limitations

Related but different: #2296 requests decompilation; #6476 fixed Unicode previews; #6438 concerns decode-limit error classification. None provides selected PYC Evidence views. NOT_ENOUGH_INFO: natural-workload frequency, cross-platform measurements, other CPython producer versions and final benefit magnitude are not established.

Originally created by @gensokyo-dev on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6922 ## Before submitting - [x] Searched open/closed issues and PRs for related PYC proposals. - [x] Reviewed contribution scope; this extends static inspection and historical Evidence querying, with no new target execution or mutation. - [x] No credentials or private target samples are included. ## Area Evidence, artifacts, or reconstruction; MCP/CLI efficiency. ## Current limitation At main `1a808dd2a239f5259af549de3a40103a03d4c05d`, answering “return every code object named parse_args, parse_known_args or _parse_known_args, with source index, qualified name, filename/line, bytecode length/SHA-256 and nested-code references” requires receiving the complete PYC report. The real stdlib argparse pyc contains 194 code objects; only three answer this question. Executed production stdio MCP discovery and inspection, checked against an independent CPython 3.11.2 marshal walk. The complete reply is **338,090 serialized bytes**, including **48,813 estimated text-reply tokens**. A one-pass input catalog, question, arguments and reply total **103,725 estimated tokens**. Raw transport catalog including output schemas is counted separately, not as model input. These use tiktoken 0.14.0/cl100k_base and a scripted SDK client with the discovered exact toolDefinition/default validator; no model ran. One fresh-session diagnostic completed in **5.055s wall / 4.675s process-family CPU / 513.2 MiB peak**. This is one baseline sample, not a speedup claim. CPython bytecode was read, never executed. Target SHA-256: `6fa55dc31dd55ddb1766369755b5cda156a42cf41193a0ff1de0189bffb4aa51` (113,662 bytes). Separate actual capability probes confirm that `detail: summary` is rejected by inspect_python_pyc's input contract, and inspect_analysis_view returns unsupported_target for retained inspect_python_pyc Evidence, including its generic summary view. ## Use cases Inspect selected nested functions/classes or compare selected bytecode identities without consuming unrelated constants/name tables. A compiler-produced small control has duplicate parse_args names; every matching code object must remain independently addressable. ## Desired outcome and success criteria - Preserve default complete output, caller budgets, byte identity, existing coverage and limitations. - Offer optional summary delivery with retained complete Evidence and an existing full-Evidence export/offline path. - Extend inspect_analysis_view with a named python-pyc code_objects collection: exact names/indices, field selection and paging; original report index stays scoped to its parent Evidence. Preserve all same-name alternatives, null/omitted values, empty selectors and empty results. - Keep nested_code as code-constant references, not a reconstructed runtime call graph. Reuse the owning parsed facts across CLI/MCP; do not reopen the artifact for historical views. - Verify real argparse plus small/compiler-produced controls with an independent CPython oracle, schema/client checks and complete-source access. Compare repeated equivalent tasks including discovery, extra calls, elapsed/family CPU/peak memory and labeled token estimates. No time/memory benefit is assumed from fewer output bytes. ## Expected interaction with targets Read existing files/captured data. Existing explicit Evidence exports write analyst-selected output files. No execution, injection, source recovery or modification of the inspected pyc; runtime inspection still requires no Python installation. ## Verification available so far Observed baseline results and independent oracle. Both complete-report workflows (real argparse and the duplicate-name control) passed with verified payload cleanup and no OOM/resource stops under CPUQuota100%, 3 GiB early stop/4 GiB hard cap. The cached prerequisite build had a transient remaining worker at payload exit; its unique scope was subsequently verified inactive and the worker absent. Final whole-scope counters are unavailable. Proposed selected delivery is not implemented yet. ## Alternatives considered / possible direction Client-side filtering receives the full report first. Current analysis views reject this parent operation. Reuse the existing retained-summary/typed-view workflow used for native exports; keep one shared projector and exact named contracts. Avoid a second parser, path cache or separate query tool. ## References and limitations Related but different: #2296 requests decompilation; #6476 fixed Unicode previews; #6438 concerns decode-limit error classification. None provides selected PYC Evidence views. NOT_ENOUGH_INFO: natural-workload frequency, cross-platform measurements, other CPython producer versions and final benefit magnitude are not established.
bsakaguchi 2026-10-31 00:47:58 +00:00
Author
Owner

@XinwangTao commented on GitHub (Oct 24, 2026):

这个方向很实用:当前查 "所有名为 parse_args 的 code object" 必须先跑完整 report 再过滤,对大的 pyc 集合开销不成比例。按需投影(只返回匹配 code object 的名称/位置/字节码元数据)能直接降低 MCP 调用延迟。三点建议:一是查询条件最好支持组合(名称 + filename/line 范围 + 嵌套引用深度),避免只能按单个名字过滤;二是返回 schema 尽量与现有 Evidence 查询的字段命名保持一致(如 source index、qualified name),减少调用方适配成本;三是给匹配结果加 limit/分页保护,防止超大 pyc 集合下一次返回过多行。PR #6928 的实现如果覆盖了这些,我可以帮忙跑一遍真实 argparse 样本做对比验证。

<!-- gh-comment-id:6378092317 --> @XinwangTao commented on GitHub (Oct 24, 2026): 这个方向很实用:当前查 "所有名为 parse_args 的 code object" 必须先跑完整 report 再过滤,对大的 pyc 集合开销不成比例。按需投影(只返回匹配 code object 的名称/位置/字节码元数据)能直接降低 MCP 调用延迟。三点建议:一是查询条件最好支持组合(名称 + filename/line 范围 + 嵌套引用深度),避免只能按单个名字过滤;二是返回 schema 尽量与现有 Evidence 查询的字段命名保持一致(如 source index、qualified name),减少调用方适配成本;三是给匹配结果加 limit/分页保护,防止超大 pyc 集合下一次返回过多行。PR #6928 的实现如果覆盖了这些,我可以帮忙跑一遍真实 argparse 样本做对比验证。
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#4239
No description provided.