Pith. sign in

REVIEW 2 major objections 5 minor 39 references

Beyond Source: An Empirical Study of Python Bytecode Security Risks

T0 review · 2 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Python bytecode in PyPI packages opens a measurable gap between what source-only scans inspect, what CPython executes, and what recovered source can represent.

desk verdict A careful, genuinely new PyPI-scale measurement of Python bytecode exposure and analyzability; the RQ3 post-ingestion execution lower bound is less certain than the abstract implies. read the letter →

arxiv 2608.12853 v1 pith:PTVHK6P5 submitted 2026-08-13 cs.CR

Baihong Chen , Tian Xie , Wen Li This is my paper · ORCID
classification cs.CR
keywords PythonbytecodePyPIpackagesecuritysoftwaresupplychainsource-less.pycfilesdecompilationanalyzabilityCPythonfuzzingruntimerobustnessinspection-executiongap
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that Python bytecode is a first-class security artifact: it ships inside PyPI packages, is executed directly by CPython, and is largely invisible to source-only security inspection. Across 1,034,843 collected wheels and source distributions, the study finds 7,388 artifacts containing 228,578 .pyc files, of which 28,193 lack any matching source file within the same artifact. Version-aware decompilers emit source for 204,901 of 204,904 modern-CPython files, so the hidden bytecode is analyzable in principle, yet the analysis tools themselves hang, throw uncaught exceptions, or die by native signal, yielding 17 distinct robustness signatures. Fuzzing mutated bytecode against CPython 3.8 through 3.14 produces 1,009 stack-deduplicated crash groups, at least 91.7% of them reaching interpreter execution beyond the documented-unsafe ingestion boundary, and none of them reproducible from ordinary Python source. The paper concludes that package-security workflows must inventory bytecode directly, analyze it with version-aware tools, triage runtime findings at the bytecode level, and stop collapsing bytecode evidence into source-level vulnerability claims.

What carries the argument

The machinery is a staged empirical pipeline held together by two distinctions. The first is the five-level analyzability ladder, L0 (not loadable) through L4 (source emitted), where L4 records only that at least one selected decompiler produced source, never that the source is semantically equivalent; the ladder lets the study separate loading, disassembly, decompilation, and faithfulness as independent failure points. The second is the ingestion-boundary split used to interpret fuzzing results: the marshal deserializer is documented as unsafe for untrusted data, so crash groups whose reproduced stacks are confined to code-object loading (25 groups) restate a known non-guarantee, while groups whose stack prefixes pass through object-runtime, frame-evaluation, garbage-collection/finalization, or instrumentation frames (925 groups, at least 91.7%) are counted as reaching post-ingestion interpreter execution. The fuzzing stage distinguishes this study from source-level campaigns: each CPython version's own unittest suite is compiled into version-correct bytecode seeds, and the serialized .pyc payloads, not the source text, are mutated and executed under the matching instrumented interpreter.

What would settle it

Rebuild the seven CPython fuzzing targets with address and memory sanitizers, re-run the campaigns, and manually root-cause each of the 1,009 stack-deduplicated crash groups. If a large share of the groups now assigned to post-ingestion execution turn out to crash inside code-object construction, deallocation, or finalization before any instruction of the mutated stream executes, the at-least-91.7% execution-boundary claim is not supported. The mirror test for the source-reproduction result is simpler: a single one of the 1,009 findings that compiles from recovered decompiler source and reproduces the same behavior class under the matching CPython version would overturn the claim that none reproduce.

Watch

Extended reading notes

Core claim

The central claim is that bytecode introduces a measurable gap between what package-security workflows inspect, what Python runtimes execute, and what source-level artifacts can faithfully represent. The evidence is staged across four research questions. Bytecode exposure is an ecosystem-scale fact: 7,388 of 1,034,843 PyPI artifacts contain .pyc files, and 12.33% of all observed .pyc files are artifact-local source-less, meaning a source-only scan never learns that they need recovery in the first place. Analyzability is high but version-dependent: with CPython-version-matched environments, PyLingual emits source for 204,901 of 204,904 in-scope files, placing all but three at level L4, defined as successful decompiler emission rather than verified functional equivalence. Robustness is a separate axis: observed PyPI bytecode produces 50 managed-code failure tool results, adversarial mutated bytecode drives decompilers into native process failures, and bytecode fuzzing across every evaluated CPython release yields 1,009 stack-deduplicated crash groups dominated by pointer-dereference symptoms, with 261 groups showing potential memory-corruption characteristics. Finally, the gap is behavioral rather than merely representational: none of the 1,009 findings is reproduced when recovered source is recompiled and rerun under the matching interpreter.

Load-bearing premise

The load-bearing premise behind the claim that at least 91.7% of crash groups reach interpreter execution beyond the unsafe-ingestion boundary is that a crash group's reproduced stack prefix reliably shows where the interpreter was when it died; if many groups attributed to object-runtime, frame-evaluation, garbage-collection, or instrumentation contexts actually crash during code-object construction, deallocation, or interpreter shutdown, before the mutated instruction stream begins executing, that lower bound is inflated.

Editorial extensions

If this is right

  • Package scanners should inventory .pyc files explicitly, record their bytecode versions, and track whether a matching source file exists in the same artifact: in the collected corpus, 28,193 executable .pyc files would otherwise escape source-only inspection.
  • Bytecode analysis needs version-aware environments and tool diversity: a single decompiler would misclassify analyzable files as opaque and hide the 50 tool-robustness failures observed on unmodified PyPI bytecode.
  • Malformed bytecode is a distinct CPython robustness boundary: every evaluated release from 3.8 to 3.14 is crash-reachable through mutated .pyc inputs, with 261 stack-deduplicated groups showing potential memory-corruption symptoms that warrant prioritized triage.
  • Bytecode-level findings should be triaged separately from source-level vulnerabilities: none of the 1,009 crash groups reproduced from recovered source, so collapsing bytecode evidence into source-level claims would misattribute the behavior.
  • Decompilers and disassemblers that process untrusted bytecode as data are part of the attack surface: adversarial .pyc inputs drove the evaluated tools into native-signal terminations through a pure data channel, giving an attacker an availability or anti-analysis primitive without any code-execution capability.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The distribution-artifact snapshot likely understates bytecode exposure in the wild: installation creates __pycache__ caches locally, and container images and private indexes fall outside the PyPI denominator, so deployment-time bytecode is probably more prevalent than the 0.71% artifact-level rate measured here.
  • The crash-reachability result suggests a concrete hardening criterion for CPython: fail on malformed bytecode through predictable, structured exceptions rather than native terminations, with invariant checks on instruction streams, constant pools, exception tables, and quickening metadata rather than only at the marshal loader.
  • A malicious package could already exploit the anti-analysis primitive without writing a crasher: a .pyc that hangs or aborts a scanner's decompiler defeats source-recovery triage while remaining executable, and the paper's own RQ2 data show such failure signatures occur on unmodified PyPI bytecode today.
  • The paper deliberately measures source emission, not semantic equivalence; a natural extension is to decompile-compile-rerun a sample of the 204,901 level-L4 files to quantify how often emitted source preserves behavior, which would sharpen the faithfulness side of the source gap.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. This paper reports a four-phase empirical study of Python bytecode as a security artifact. Phase 1 inventories bytecode in a package-balanced sample of PyPI wheels and source distributions (1,034,843 artifacts; 7,388 with .pyc files; 228,578 .pyc files; 28,193 artifact-local source-less .pyc files). Phase 2 measures version-aware analyzability with marshal, dis, Decompyle++, and PyLingual, finding that 204,901 of 204,904 in-scope CPython 3.8-3.14 .pyc files reach L4 (at least one decompiler emits source), with 50 tool robustness failures collapsing to 6 signatures. Phase 3 fuzzes CPython 3.8-3.14 with mutated .pyc seeds over seven 24-hour single-worker honggfuzz campaigns, yielding 12,404 crash inputs, 1,009 stack-deduplicated groups, 261 groups with potential memory-corruption symptoms, and a claim that at least 91.7% of groups reach post-ingestion execution. Phase 4 attempts to reproduce the 1,009 findings from source recovered by PyLingual and Decompyle++, reporting that none reproduce and that decompilers show 11 additional robustness signatures. The paper repeatedly and explicitly scopes its claims: L4 means source emission, not semantic equivalence; RQ3 findings are lower-bound reachability evidence, not exploitability; RQ4 is tool-bounded. The artifact release includes PycLens and manifests, with crash-triggering inputs gated pending disclosure.

Significance. If the central claims survive review, the paper makes a solid empirical contribution: it demonstrates at scale that executable bytecode is present in PyPI artifacts beyond source-visible content, that current decompilers can emit source for most modern bytecode while failing on a non-trivial subset, and that malformed bytecode can crash CPython in many distinct paths. The explicit separation of source emission from semantic equivalence, the distinction between executing and load-but-do-not-execute consumers, and the public tooling are strengths. The paper's main limitation is that its headline 'at least 91.7% post-ingestion execution' and the unqualified 'None reproduce from ordinary Python source' are stronger than the evidence supports; both are addressed by concrete, feasible fixes.

major comments (2)
  1. [§5.3.2 and Table 16] The 'at least 91.7% of groups reach execution beyond the documented-unsafe ingestion boundary' claim is not established by the presented evidence. The runtime-context labels are assigned from normalized stack prefixes, and the paper provides no criterion for distinguishing a crash during code-object construction, quickening, or deallocation from a crash after the mutated instruction stream begins executing. The representative CPython 3.13 group with stack prefix _Py_GetBaseOpcode/_PyCode_Quicken/_PyCode_New in Table 17 is itself described as a loading-time crash, yet Table 16 assigns only 12 of 198 CPython 3.13 groups to 'Code object'; if similar frames can appear in groups labeled 'Object runtime' or 'GC/final.', the 91.7% lower bound is inflated. Because the abstract and Section 6.2 use this number to argue that hardening must extend beyond marshal, the classification must be validated. I request a phase-instrumented replay of the 1,009 groups that records whether _PyEval_EvalFrameDefault (or the equivalent evaluation entry point) was entered for the mutated code object before the fault, or, if that is infeasible, a rewording of the claim to describe the stack-prefix distribution rather than post-ingestion execution.
  2. [Abstract and §5.4] The sentence 'None reproduce from ordinary Python source' overstates the tool-bounded negative result. The experiment shows that two selected decompilers, PyLingual and Decompyle++, did not emit source that compiles and reproduces any of the 1,009 findings; §5.4.1 itself labels the categories 'tool-bounded.' Because the inputs are bytecode mutations that the CPython source compiler does not produce, the result conflates a representational gap with decompiler limitations on malformed inputs. The abstract and conclusion should be reworded to 'none reproduce through the evaluated source-recovery workflows,' and Section 1's claim that behavior 'need not match source-level behavior' should be qualified accordingly. A stronger design would also run the original pre-mutation seed source as a control to confirm that the crash is not source-reachable, although even such a control would not rule out other source-level programs.
minor comments (5)
  1. [§5.1.3, Table 7] The 'Plausible cause' categories are inferred from path shape, but the path-shape heuristics are not described; please state how 'accidental import cache' is distinguished from 'bundled environment cache' and 'bare compiled-only module.'
  2. [§5.3.1] The citation [12] after 'Honggfuzz retained 12,404 crash-triggering inputs' appears to reference Klees et al. on fuzz testing evaluation, not the honggfuzz tool; either cite the honggfuzz reference [9] or move [12] to the sentence about point estimates.
  3. [§4.4] The phrase 'without conflating those states with bytecode/interpreter mismatch' is ambiguous; clarify whether this means version mismatch between bytecode tag and interpreter or some other mismatch.
  4. [§5.2.2, Table 11] The 'Translation failure' category is described as necessarily zero in RQ2 because RQ2 does not exercise decompile-compile-rerun; consider moving this explanation to the table caption or a footnote for readability.
  5. [Section 1, paragraph 2] The sentence 'bytecode can be consumed directly by Python runtimes, making untrusted or malformed bytecode part of the interpreter-facing attack surface' is a reasonable claim, but the sentence could note that the paper does not establish exploitability, aligning with Table 1; consider adding 'in terms of robustness' for precision.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's claims are empirical measurements over external artifacts, tools, and interpreters, with self-citations used only as related-work positioning.

full rationale

The paper derives no prediction from a fitted parameter. Its central claims are direct measurements: bytecode counts from 1,034,843 collected PyPI artifacts, decompiler emission rates from pinned external tools (marshal, dis, Decompyle++, PyLingual), and crash groups from instrumented CPython builds. The L4 metric is explicitly defined as successful source emission without verified functional equivalence, so the paper does not rename decompiler output as semantic recovery. The RQ3 'at least 91.7% reach execution beyond the documented-unsafe ingestion boundary' is an inference from stack-prefix categories in Table 16, not an equation that reduces to its inputs; the paper assigns the 59 unknown groups to the non-execution side to make the share a lower bound, and Section 5.3.2 together with threats T5 and T6 disclose the absence of sanitizer builds, the symptom-based nature of Class B labels, and the single-campaign stochasticity. Whether the Object runtime/GC/final./Instrument. labels overcount post-ingestion execution is a validity risk about classification, not a circular structure. The only self-citations to prior work by the authors (Pyrtfuzz [16] and PolyFuzz [15]) are used for contrast: Pyrtfuzz is described as mutating source/runtime API inputs and thereby reaching the interpreter through the ordinary compilation path, while this study mutates serialized bytecode seeds directly. That contrast is a related-work delimitation, not a load-bearing premise, and no uniqueness theorem or ansatz is imported from the authors' prior work. The results stand against external, pinned, version-matched artifacts and an external interpreter implementation, so the derivation chain is self-contained.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new particles, forces, or formal objects; PycLens is a pipeline tool rather than an invented entity. The listed free parameters are hand-chosen experimental thresholds that shape specific counts, while the axioms are the background assumptions needed to interpret the empirical measurements as security-relevant findings.

free parameters (3)
  • Fuzzing campaign budget per CPython version = 24 hours, 1 worker, no repetitions
    Controls how many crash inputs are found; the paper itself labels the count a lower-bound point estimate without confidence intervals (Section 5.3, Threat T6).
  • Decompiler timeout threshold = 600 seconds
    Determines which tool runs are recorded as timeouts in RQ2 and RQ4 robustness signatures (Tables 12, 20).
  • Dynamic-loading indicator pattern set = 7 textual patterns (marshal., marshal.loads(, importlib, SourcelessFileLoader, exec(, eval(, types.CodeType/CodeType())
    Directly sets the 23.44% dynamic-loading artifact prevalence; the authors state it was not validated by a hand-labeled precision study (Section 4.2, Threat T3).
assumptions (4)
  • domain assumption CPython magic numbers and filename tags are reliable evidence of the interpreter version that generated a .pyc file.
    RQ2's version-aware scoping and the 204,904 in-scope denominator depend on this mapping (Section 4.2, Table 6).
  • domain assumption Stack-prefix categories in Table 16 separate ingestion-phase crashes from post-ingestion execution crashes.
    The 91.7% reachability claim is computed from this classification, which is not root-cause validated.
  • domain assumption A 24-hour single-worker honggfuzz campaign with no sanitizer builds is sufficient to demonstrate crash reachability for each CPython version.
    The authors explicitly scope RQ3 as an existence claim and lower-bound evidence (Section 5.3, T6).
  • domain assumption CPython's unittest suite, compiled to bytecode, is a reasonable seed corpus for adversarial bytecode mutation.
    The fuzzing pipeline uses these seeds to generate malformed bytecode; if they are unrepresentative, some crash classes could be missed (Section 4.4).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Beyond Source: An Empirical Study of Python Bytecode Security Risks." pith.science (2026). https://pith.science/paper/PTVHK6P5

@misc{pith2026260812853,
  author       = {Pith},
  title        = {Pith review of: Beyond Source: An Empirical Study of Python Bytecode Security Risks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PTVHK6P5}},
  note         = {Machine review of arXiv:2608.12853}
}
read the original abstract

Python package security is largely source-centric, yet Python runtimes can execute bytecode directly through .pyc files, compiled-only modules, and marshalled code objects, creating an inspection-execution gap. We present an empirical study of Python bytecode as a security artifact. We measure bytecode exposure in PyPI distributions, evaluate practical analyzability using version-aware tooling, assess CPython runtime robustness under adversarial bytecode, and test source-level reproduction of bytecode findings. Across 1,034,843 collected PyPI artifacts, we identify 7,388 bytecode-containing artifacts, including 228,578 .pyc files and 28,193 artifact-local source-less .pyc files. For modern CPython 3.8-3.14 bytecode, at least one selected decompiler emits source for 204,901 of 204,904 in-scope files, a result measuring emission rather than verified functional equivalence. Tools are non-robust: observed PyPI bytecode triggers managed-code exceptions and timeouts, while adversarial mutated bytecode also drives decompilers into native process failures; together these outcomes yield 17 distinct robustness signatures. Fuzzing produces 1,009 stack-deduplicated runtime findings dominated by pointer-dereference symptoms; 261 groups exhibit potential memory-corruption characteristics, and at least 91.7% of groups reach execution beyond the documented-unsafe ingestion boundary. None reproduce from ordinary Python source. Bytecode is thus a visible ecosystem artifact, a practical analysis target, and a security-relevant interpreter input whose behavior need not match source-level behavior.

Figures

Figures reproduced from arXiv: 2608.12853 by the authors.

Figure 1
Figure 1. Overview of the empirical study pipeline. The four phases correspond to bytecode exposure and packaging (RQ1), practical [PITH_FULL_IMAGE:figures/full_fig_p008_1.png] view at source ↗
Figure 2
Figure 2. Version-aware workflow for evaluating CPython robustness under adversarial bytecode. Each CPython version is processed [PITH_FULL_IMAGE:figures/full_fig_p013_2.png] view at source ↗
Figure 3
Figure 3. Tool-support architecture of PycLens. A pipeline orchestrator coordinates dataset construction, bytecode inspection, CPython￾environment preparation, and fuzzing/reproduction workflows through a shared artifact workspace that stores intermediate datasets, findings, reports, and logs [PITH_FULL_IMAGE:figures/full_fig_p015_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 28 canonical work pages

  1. [1]

    Mahmoud Alfadel, Diego Elias Costa, and Emad Shihab. 2023. Empirical Analysis of Security Vulnerabilities in Python Packages.Empirical Software Engineering28, 3 (2023), 59. doi:10.1007/s10664-022-10278-4

    doi:10.1007/s10664-022-10278-4 2023

  2. [2]

    Marcel Böhme, Van-Thuan Pham, and Abhik Roychoudhury. 2016. Coverage-based greybox fuzzing as markov chain. InProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. 1032–1043

    work page 2016

  3. [3]

    Ethan Bommarito and Michael Bommarito. 2019. An Empirical Analysis of the Python Package Index (PyPI).arXiv preprint arXiv:1907.11073(2019). https://arxiv.org/abs/1907.11073

    arXiv 2019

  4. [4]

    Decompyle++ Developers. 2026. Decompyle++: A Python Byte-code Disassembler/Decompiler. https://github.com/zrsx/pycdc

    work page 2026

  5. [5]

    Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformaggio, and Wenke Lee. 2021. Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages. InProceedings of the Network and Distributed System Security Symposium (NDSS). https://www.ndss-symposium.org/ndss-paper/towards-measuring-supply-chain-attacks-on-packa...

    work page 2021

  6. [6]

    Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. 2020. AFL++: Combining incremental steps of fuzzing research. In14th{USENIX} Workshop on Offensive Technologies ({WOOT}20)

    work page 2020

  7. [7]

    2025.{MalGuard}: Towards{Real- Time}, Accurate, and Actionable Detection of Malicious Packages in{PyPI} Ecosystem

    Xingan Gao, Xiaobing Sun, Sicong Cao, Kaifeng Huang, Di Wu, Xiaolei Liu, Xingwei Lin, and Yang Xiang. 2025.{MalGuard}: Towards{Real- Time}, Accurate, and Actionable Detection of Malicious Packages in{PyPI} Ecosystem. In34th USENIX Security Symposium (USENIX Security 25). 4741–4758

    work page 2025

  8. [8]

    google. 2022. Continuous Fuzzing Framework for Open Source Software. https://github.com/google/oss-fuzz

    2022

Show all 39 references
  1. [9]

    Google. 2026. honggfuzz. https://github.com/google/honggfuzz

    2026

  2. [10]

    Wenbo Guo, Zhengzi Xu, Chengwei Liu, Cheng Huang, Yong Fang, and Yang Liu. 2023. An Empirical Study of Malicious Code In PyPI Ecosystem. arXiv preprint arXiv:2309.11021(2023). https://arxiv.org/abs/2309.11021

    2023 arXiv

  3. [11]

    Nicolas Harrand, César Soto-Valero, Martin Monperrus, and Benoit Baudry. 2019. The strengths and behavioral quirks of Java bytecode decompilers. In2019 19th International working conference on source code analysis and manipulation (SCAM). IEEE, 92–102

    2019

  4. [12]

    George Klees, Andrew Ruef, Benji Cooper, Shiyi Wei, and Michael Hicks. 2018. Evaluating fuzz testing. InProceedings of the 2018 ACM SIGSAC conference on computer and communications security. 2123–2138

    2018

  5. [13]

    Patrick Lam, Eric Bodden, Ondrej Lhoták, and Laurie Hendren. 2011. The Soot framework for Java program analysis: a retrospective. InCetus Users and Compiler Infastructure Workshop (CETUS 2011), Vol. 15

    2011

  6. [14]

    Chris Lattner and Vikram Adve. 2004. LLVM: A compilation framework for lifelong program analysis & transformation. InInternational Symposium on Code Generation and Optimization, 2004. CGO 2004.IEEE, 75–86

    2004

  7. [15]

    Wen Li, Jinyang Ruan, Guangbei Yi, Long Cheng, Xiapu Luo, and Haipeng Cai. 2023. PolyFuzz: Holistic Greybox Fuzzing of Multi-Language Systems. In32nd USENIX Security Symposium (USENIX Security 23). 1379–1396

    2023

  8. [16]

    Wen Li, Haoran Yang, Xiapu Luo, Long Cheng, and Haipeng Cai. 2023. Pyrtfuzz: Detecting bugs in python runtimes via two-level collaborative fuzzing. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 1645–1659

    2023

  9. [17]

    Valentin J. M. Manes, HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J. Schwartz, and Maverick Woo. 2019. The Art, Science, and Engineering of Fuzzing: A Survey. arXiv:1812.00140 [cs.CR] https://arxiv.org/abs/1812.00140

    2019 arXiv

  10. [18]

    Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. 2020. Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks. InProceedings of the 17th International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMV...

    2020 doi

  11. [19]

    Benjamin Peterson. 2017. PEP 552 – Deterministic pycs. Python Enhancement Proposal. https://peps.python.org/pep-0552/

    2017

  12. [20]

    PyLingual Developers. 2026. PyLingual: Python Decompiler for Modern Python Versions. https://github.com/syssec-utd/pylingual

    2026

  13. [21]

    Python Package Index. 2026. Index API. https://docs.pypi.org/api/index-api/

    2026

  14. [22]

    Python Package Index. 2026. JSON API. https://docs.pypi.org/api/json/

    2026

  15. [23]

    Python Package Index. 2026. PyPI Documentation. https://docs.pypi.org/

    2026

  16. [24]

    Python Packaging Authority. 2026. Package Formats. https://packaging.python.org/en/latest/discussions/package-formats/

    2026

  17. [25]

    Python Packaging Authority. 2026. The Packaging Flow. https://packaging.python.org/en/latest/flow/

    2026

  18. [26]

    Python Software Foundation. 2026. CPython Test Suite. https://github.com/python/cpython/tree/main/Lib/test

    2026

  19. [27]

    Python Software Foundation. 2026. dis – Disassembler for Python bytecode. https://docs.python.org/3/library/dis.html

    2026

  20. [28]

    Python Software Foundation. 2026. importlib — The implementation of import. Python documentation. https://docs.python.org/3/library/importlib. html

    2026

  21. [29]

    Python Software Foundation. 2026. marshal – Internal Python object serialization. https://docs.python.org/3/library/marshal.html

    2026

  22. [30]

    Python Software Foundation. 2026. py_compile – Compile Python source files. https://docs.python.org/3/library/py_compile.html

    2026

  23. [31]

    Python Software Foundation. 2026. Python Developer’s Guide: Running and Writing Tests. https://devguide.python.org/testing/run-write-tests/. Manuscript submitted to ACM 36 Baihong Chen, Tian Xie, and Wen Li

    2026

  24. [32]

    2012.{AddressSanitizer}: A fast address sanity checker

    Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitriy Vyukov. 2012.{AddressSanitizer}: A fast address sanity checker. In 2012 USENIX annual technical conference (USENIX ATC 12). 309–318

    2012

  25. [33]

    Gang Tan and Greg Morrisett. 2007. ILEA: Inter-language analysis across Java and C. InProceedings of the 22nd annual ACM SIGPLAN conference on Object-oriented programming systems, languages and applications. 39–56

    2007

  26. [34]

    Vaidya, Drew Davidson, Lorenzo De Carli, and Vaibhav Rastogi

    Matthew Taylor, Ruturaj K. Vaidya, Drew Davidson, Lorenzo De Carli, and Vaibhav Rastogi. 2020. SpellBound: Defending Against Package Typosquatting.arXiv preprint arXiv:2003.03471(2020). https://arxiv.org/abs/2003.03471

    2020 arXiv

  27. [35]

    Rijnard Van Tonder, John Kotheimer, and Claire Le Goues. 2018. Semantic crash bucketing. InProceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering. 612–622

    2018

  28. [36]

    Junjie Wang, Bihuan Chen, Lei Wei, and Yang Liu. 2017. Skyfire: Data-driven seed generation for fuzzing. In2017 IEEE Symposium on Security and Privacy (SP). IEEE, 579–594

    2017

  29. [37]

    Barry Warsaw. 2009. PEP 3147 – PYC Repository Directories. Python Enhancement Proposal. https://peps.python.org/pep-3147/

    2009

  30. [38]

    Kaichao You, Runsheng Bai, Meng Cao, Jianmin Wang, Ion Stoica, and Mingsheng Long. 2025. depyf: Open the Opaque Box of PyTorch Compiler for Machine Learning Researchers.Journal of Machine Learning Research26, 25 (2025), 1–18. http://jmlr.org/papers/v26/24-0383.html

    2025

  31. [39]

    Tai Yue, Pengfei Wang, Yong Tang, Enze Wang, Bo Yu, Kai Lu, and Xu Zhou. 2020. EcoFuzz: Adaptive Energy-Saving Greybox Fuzzing as a Variant of the Adversarial Multi-Armed Bandit. In29th{USENIX}Security Symposium. 2307–2324. Manuscript submitted to ACM

    2020

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.