René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Feature Request: Feature Parity between Java and Python Analysis","articleBody":"**Is your feature request related to a problem? Please describe.**\n\nCurrently, CLDK's support for analyzing Python source code via `codeanalyzer-python` is limited in comparison to the Java capabilities available in `codeanalyzer-java`. While the Java backend supports deep semantic extraction including symbol tables, call graphs, control/data flow graphs, CRUD operation detection, and framework-specific analyses, the Python counterpart lacks many of these features. This asymmetry makes it hard to build language-agnostic tooling and limits reuse of the CLDK analysis stack for Python-heavy projects.\n\n**Describe the solution you'd like**\n\nI’d like CLDK to offer parity between its Java and Python analysis capabilities, ideally exposing the same abstraction surfaces. This includes:\n\n- A fully-featured `PyApplication` schema with semantic depth matching `JApplication`\n- Robust symbol resolution using `jedi`, LSP, and other tools to handle module/function/class-level scoping, type inference, imports, and dynamic features\n- Generation of call graphs (direct + transitive), with support for async and dynamic callsites\n- Control and data flow graphs at the function and module level\n- Basic interprocedural analysis across modules and packages\n- CRUD operation detection and annotation in frameworks like Django, SQLAlchemy, FastAPI, etc.\n- Support for incremental/eager analysis and caching like the Java analyzer\n- Compatibility with existing CLDK pipelines like test generation, transformation, and migration agents\n\n**Describe alternatives you've considered**\n\n- Wrapping third-party static analysis tools like Pyright, pyre, or mypy — but these often lack consistent and unified schema output\n- Rewriting analyses from scratch for Python — not ideal due to duplication and maintenance burden\n- Falling back on AST-based pattern matching without semantic resolution — brittle and low precision\n\n**Additional context**\n\nReference implementations and design can be found in:\n- https://github.com/codellm-devkit/codeanalyzer-java\n- https://github.com/codellm-devkit/codeanalyzer-python\n\nThe goal is to bring `codeanalyzer-python` up to parity with `codeanalyzer-java` in CLDK’s analysis infrastructure. This will enable unified workflows across Java and Python ecosystems and allow tool developers to target a shared intermediate representation for static analysis tasks.","author":{"url":"https://github.com/rahlk","@type":"Person","name":"rahlk"},"datePublished":"2025-07-22T14:04:08.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/137/python-sdk/issues/137"}