Suggestion to refactor types.py

[adityamehra]

Description

• Move from inheritance to composition
• Suggestions are in types_redesign.py and the document is ARCHITECTURE_RECOMMENDATION.md
• Focus on extensibility, understandability, readability and backwards compatibility

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Test A

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[adityamehra]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

[chatgpt-codex-connector]

Preserve keyword-only init for GenAI subclasses

Dropping kw_only=True from the GenAI dataclass changes the generated __init__ signature so all base fields become positional and are inserted before subclass fields. Previously subclasses like LLMInvocation or ToolCall could be instantiated positionally (LLMInvocation("gpt-4")) because the base attributes were keyword-only. After this change the same call now binds the argument to context_token and leaves request_model at its default, silently emitting spans with missing model information. This is a backward‑incompatible break for any consumer using positional arguments and will produce incorrect telemetry. Consider retaining kw_only=True or otherwise preserving the previous constructor signature.

Useful? React with 👍 / 👎.

[adityamehra]

@codex review

✅ Why This Solution Works Perfectly

Critical Discovery: Keyword-Only Usage Pattern

After reviewing actual usage in the codebase (particularly callback_handler.py), we found that 100% of instantiations use keyword arguments:

Pattern 1: LLM Invocation (lines 1055-1084)

llm_kwargs: dict[str, Any] = {
    "request_model": request_model,
    "provider": provider_name,
    "framework": "langchain",
    "input_messages": input_messages,
    "request_functions": request_functions,
    "attributes": attributes,
}
# Conditionally add more kwargs...
inv = UtilLLMInvocation(**llm_kwargs)  # ✅ Keyword arguments

Pattern 2: Agent Invocation (lines 604-616)

agent = UtilAgent(
    name=name,
    operation=operation,
    agent_type=agent_type,
    description=description,
    framework=framework,
    model=model,
    tools=tools,
    system_instructions=system_instructions,
    attributes=attributes,
    run_id=run_id,
    parent_run_id=parent_run_id,
)  # ✅ All keyword arguments

Pattern 3: Input Messages (lines 829-832)

result.append(
    UtilInputMessage(
        role=role, 
        parts=[UtilText(content=str(content))]
    )
)  # ✅ Keyword arguments

Why Positional Arguments Were Never a Risk

1. Codebase Convention: The entire codebase uses a consistent pattern of keyword arguments
2. Builder Pattern: Most invocations build a kwargs dictionary first, then use **kwargs unpacking
3. Explicit Fields: All calls explicitly name the parameters they're passing
4. No Positional Usage: We found zero instances of positional instantiation like LLMInvocation("gpt-4")

---

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Bravo.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

[keith-decker]

Can we split the architecture recommendation from the python3.9 fixes?

[adityamehra]

Can we split the architecture recommendation from the python3.9 fixes?

@keith-decker Here's the PR with just changes for python3.9 without the architecture recommendation - #26.

This PR was built on top of the one for just python3.9. I agree that the one with just python3.9 fixes should go in first as this one is more of a POC.