Fix: resolve "import as" statements in deconstruct flow #423
Conversation
Summary of ChangesHello @haggit-eliyahu, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request resolves an issue with how Python 'import ... as ...' statements are processed by the project's code manipulation tools. Previously, these statements were not correctly transformed, especially when converting standard 'import' syntax to 'from ... import ...' for internal and SDK modules. The changes ensure that the 'as' alias is preserved during these transformations, enhancing the robustness of the code refactoring utilities and preventing potential import errors. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly addresses an issue where import ... as ... statements were not handled properly by the import transformers, causing aliases to be lost. The changes successfully preserve aliases and handle more complex import patterns. The accompanying tests are thorough and cover these new scenarios well.
However, I've identified a critical pre-existing issue in how import statements with multiple names (e.g., import os, sys) are processed. The current logic can lead to silently dropping imports, which could break code. I have provided two review comments with suggestions to address this critical bug, ensuring the transformers are more robust.
haggit-eliyahu
changed the title
haggit-eliyahu
force-pushed
the
small-fix-in-imports-deconstruct
branch
from
688df18 to
4df4e4c
Compare
haggit-eliyahu
force-pushed
the
small-fix-in-imports-deconstruct
branch
from
65efbb2 to
4349b37
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request extends the import transformation logic to handle import ... as ... and multi-module import statements. While the added test cases cover many new scenarios, the implementation in both CorePackageImportTransformer and CorePackageInternalImportTransformer contains a critical flaw. The logic incorrectly assumes all modules on a single import line are of the same type and structure, based only on the first module. This can lead to generating invalid import statements when mixed imports are present. I've left detailed comments on the specific transformers with examples of the failing cases. These issues should be addressed, and the test suite should be expanded to include these negative test cases to ensure correctness.
| if not original_node.names: | ||
| return updated_node | ||
|
|
||
| first_module_part: str = full_module_name.split(".", maxsplit=1)[0] | ||
| first_alias = updated_node.names[0] | ||
| full_module_name: str | None = get_full_name_for_node(first_alias.name) | ||
| if not full_module_name or full_module_name.split(".")[0] not in self.core_module_names: | ||
| return updated_node | ||
|
|
||
| new_aliases: list[cst.ImportAlias] = [] | ||
| parts: list[str] = full_module_name.split(".") | ||
|
|
||
| if len(parts) > 1: | ||
| # Case: `import manager.submodule.func, manager.submodule.other_func` | ||
| module_path: str = ".".join(parts[:-1]) | ||
| prefixed_module = _create_prefixed_module(module_path, CORE_PREFIX) | ||
|
|
||
| for alias in updated_node.names: | ||
| alias_full_name = get_full_name_for_node(alias.name) | ||
| if alias_full_name: | ||
| imported_name = alias_full_name.split(".")[-1] | ||
| new_aliases.append( | ||
| cst.ImportAlias( | ||
| name=cst.Name(value=imported_name), | ||
| asname=alias.asname, | ||
| ) | ||
| ) | ||
|
|
||
| if first_module_part in self.core_module_names: | ||
| return cst.ImportFrom( | ||
| module=cst.Name(value="core"), | ||
| names=[cst.ImportAlias(name=cst.Name(value=first_module_part))], | ||
| module=prefixed_module, | ||
| names=new_aliases, | ||
| relative=(cst.Dot(), cst.Dot()), | ||
| ) | ||
|
|
||
| return updated_node | ||
| # Case: `import manager, other_manager` -> `from ..core import manager, other_manager` | ||
| for alias in updated_node.names: | ||
| alias_full_name = get_full_name_for_node(alias.name) | ||
| if alias_full_name: | ||
| new_aliases.append( | ||
| cst.ImportAlias(name=cst.Name(value=alias_full_name), asname=alias.asname) | ||
| ) | ||
|
|
||
| return cst.ImportFrom( | ||
| module=cst.Name(value="core"), | ||
| names=new_aliases, | ||
| relative=(cst.Dot(), cst.Dot()), | ||
| ) |
There was a problem hiding this comment.
This new logic to handle multiple imports on one line has a flaw when dealing with mixed import types. The decision to transform the entire import statement is based only on the first imported module (first_alias). This can lead to incorrect code generation.
Here are a couple of scenarios where it fails:
-
Mixing core and non-core modules:
An import likeimport manager, requests(assumingmanageris a core module andrequestsis not) will be incorrectly transformed intofrom ..core import manager, requests, which will cause anImportErrorbecauserequestsis not in..core. -
Mixing top-level and sub-module imports:
An import likeimport manager.submodule, manager2will be incorrectly transformed intofrom ..core.manager import submodule, manager2, which is wrong becausemanager2is not part of the..core.managermodule.
The transformation should only proceed if all modules on the line are of a compatible type and structure. You should either validate all modules before transforming or choose not to transform ambiguous multi-import statements.
Please also add test cases for these failing scenarios to prevent regressions.
| if not original_node.names: | ||
| return updated_node | ||
|
|
||
| full_module_name: str | None = get_full_name_for_node(original_node.names[0].name) | ||
| # Check first alias to see if we need to transform | ||
| first_alias = updated_node.names[0] | ||
| full_module_name: str | None = get_full_name_for_node(first_alias.name) | ||
| if not full_module_name: | ||
| return updated_node | ||
|
|
||
| if ( | ||
| full_module_name in self.core_module_names | ||
| and full_module_name != self.current_module_name | ||
| parts: list[str] = full_module_name.split(".") | ||
| first_module_part: str = parts[0] | ||
|
|
||
| if not ( | ||
| first_module_part in self.core_module_names | ||
| and first_module_part != self.current_module_name | ||
| ): | ||
| return updated_node | ||
|
|
||
| new_aliases: list[cst.ImportAlias] = [] | ||
|
|
||
| if len(parts) > 1: | ||
| # Case: `import constants.func, constants.other_func` | ||
| # -> `from .constants import func, other_func` | ||
| module_path: str = ".".join(parts[:-1]) | ||
| module_expr = cst.parse_expression(module_path) | ||
|
|
||
| for alias in updated_node.names: | ||
| alias_full_name = get_full_name_for_node(alias.name) | ||
| if alias_full_name: | ||
| imported_name = alias_full_name.split(".")[-1] | ||
| new_aliases.append( | ||
| cst.ImportAlias( | ||
| name=cst.Name(value=imported_name), | ||
| asname=alias.asname, | ||
| ) | ||
| ) | ||
|
|
||
| return cst.ImportFrom( | ||
| module=None, | ||
| names=[cst.ImportAlias(name=cst.Name(value=full_module_name))], | ||
| module=cast("cst.Attribute | cst.Name", module_expr), | ||
| names=new_aliases, | ||
| relative=(cst.Dot(),), | ||
| ) | ||
|
|
||
| return updated_node | ||
| # Case: `import constants, utils` -> `from . import constants, utils` | ||
| for alias in updated_node.names: | ||
| alias_full_name = get_full_name_for_node(alias.name) | ||
| if alias_full_name: | ||
| new_aliases.append( | ||
| cst.ImportAlias(name=cst.Name(value=alias_full_name), asname=alias.asname) | ||
| ) | ||
|
|
||
| return cst.ImportFrom( | ||
| module=None, | ||
| names=new_aliases, | ||
| relative=(cst.Dot(),), | ||
| ) |
There was a problem hiding this comment.
Similar to the CorePackageImportTransformer, this transformer's logic for handling multiple imports is flawed because it only inspects the first module on the line to decide how to transform the entire statement.
This can cause incorrect transformations in these cases:
-
Mixing internal core modules with other modules:
import constants, some_external_libwould be incorrectly changed tofrom . import constants, some_external_lib, leading to anImportError. -
Mixing different internal core modules with different structures:
import constants.func, utils.helperwould be incorrectly transformed tofrom .constants import func, helper, which is invalid becausehelperis not inconstants.
To fix this, the logic needs to validate all imported items on the line to ensure they are compatible before applying the transformation. It would also be beneficial to add negative test cases to cover these scenarios.
# Conflicts: # packages/mp/pyproject.toml # packages/mp/uv.lock
haggit-eliyahu
force-pushed
the
small-fix-in-imports-deconstruct
branch
from
4349b37 to
9682092
Compare
haggit-eliyahu
force-pushed
the
small-fix-in-imports-deconstruct
branch
from
9682092 to
5e2a9d6
Compare
2 participants
Description
handle statements of the format "import * as *".
some cases has to change it to "from * import * as *" due to using relative path.
Checklist:
Please ensure you have completed the following items before submitting your PR.
This helps us review your contribution faster and more efficiently.
General Checks:
Open-Source Specific Checks:
For Google Team Members and Reviewers Only:
Screenshots (If Applicable)
If your changes involve UI or visual elements, please include screenshots or GIFs here.
Ensure any sensitive data is redacted or generalized.
Further Comments / Questions
Any additional comments, questions, or areas where you'd like specific feedback.