Skip to content

5933 fixing loopy imports#98

Open
harshi922 wants to merge 4 commits intodevelopfrom
5933-fixing-loopy-imports
Open

5933 fixing loopy imports#98
harshi922 wants to merge 4 commits intodevelopfrom
5933-fixing-loopy-imports

Conversation

@harshi922
Copy link
Copy Markdown
Contributor

#5933

Okay this is a big change but this makes it possible to not define types in CFX 3X. Tested against actual GHA CFX - all ok! Will work in server func logic similarly once this gets changes suggested and resolved!

@harshi922 harshi922 requested a review from aarongoin February 19, 2026 21:44
@aarongoin aarongoin requested a review from eneumann February 19, 2026 22:23
@aarongoin
Copy link
Copy Markdown
Member

Going to pull Eric in since his Python knowledge far exceeds mine!

Copy link
Copy Markdown
Member

@eneumann eneumann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work on this refactor @harshi922!
A few of these edge cases look like the kind that static typing catches early (especially around optional TypedDict keys and changed return contracts). It may be worth adding a stronger type-checking extension to your vscode so you can spot these early on.
For example, my user settings (global settings) for python uses Pyright via Pylance in basic mode. Then most projects i work with also use mypy.



def render_spec(spec: SpecificationDto) -> Tuple[str, str]:
def render_spec(spec: SpecificationDto) -> Tuple[str, str, str]:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this return-contract change, please make sure all callers can handle it (e.g. correct unpacking for all three values) This one in rendered_spec.py will break -> func_str, type_defs = render_spec(spec)

f"'{function_name}', function unavailable: \" + str(e))"
)

indented = '\n '.join(runtime_code.split('\n'))
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible this can generate invalid Python when there’s no runtime code left after type extraction (e.g. some function that only defines types). In that case we still emit a try: block with an empty body, which causes an error. Let's add a fallback like pass, when runtime_code is empty just to be safe.

module_scope_names: set[str] = set(class_names)

# Get all module-level assigned symbol names for reference
module_level_symbols: set[str] = {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there’s one runtime edge case here: class definitions can be moved to module scope before their imported dependencies are available. For example, with import pydantic + class A(pydantic.BaseModel), the class may be emitted outside the try, while import pydantic stays inside it. Can we treat imported symbols as module-scope dependencies too, so classes and their required imports stay aligned?

prefix = """logger = logging.getLogger("poly")
try:
# X = Literal[...], X = Dict[str, Any], X = list[Foo], X = Union[...]
if isinstance(node, ast.Subscript):
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this check might be a bit too broad and could move some regular code into the type section, which could unintentionally change runtime behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants