refactor(core): standard content blocks #32085
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
|
||
|
|
||
| def is_data_content_block( |
There was a problem hiding this comment.
I don't mind updating the types but I don't think we should break untyped dicts in these formats in 0.4 if we can avoid it. If we decide to migrate IMO we should retain backward compatibility and emit deprecation warnings in the appropriate code paths (you may be able to just add a warning to is_data_content_block but we'll need to check integrations).
… update ReasoningContentBlock structure
…reat each step as a distinct block in a list
| """Signature of the reasoning. | ||
|
|
||
| Inspired by: | ||
| - https://ai.google.dev/gemini-api/docs/thinking#signatures |
There was a problem hiding this comment.
AFAIK Gemini doesn't include signature on thinking parts, rather on text with thought=False or function calls.
mdrxy
changed the title
CodSpeed WallTime Performance ReportMerging #32085 will not alter performanceComparing
|
CodSpeed Instrumentation Performance ReportMerging #32085 will not alter performanceComparing Summary
|
| mime_type: Literal["text/plain"] | ||
| """MIME type of the file. Required for base64.""" | ||
|
|
||
| base64: str |
There was a problem hiding this comment.
Required base64 field conflicts with optional text field. If text is optional when base64 is provided, then base64 should probably be NotRequired as well to allow for text-only usage.
| base64: str | |
| base64: NotRequired[str] |
Copilot uses AI. Check for mistakes.
| base64: str | ||
| """Data as a base64 string.""" |
There was a problem hiding this comment.
Required base64 field is inconsistent with the presence of optional file_id field. If content can be provided via file_id, then base64 should be NotRequired to allow for ID-only usage.
| base64: str | |
| """Data as a base64 string.""" | |
| base64: NotRequired[str] | |
| """Data as a base64 string. Optional if `file_id` is provided.""" |
Copilot uses AI. Check for mistakes.
| except ValidationError: | ||
| return False | ||
| else: | ||
| return True | ||
|
|
||
|
|
||
| # These would need to be refactored | ||
| def convert_to_openai_image_block(content_block: dict[str, Any]) -> dict: | ||
| """Convert image content block to format expected by OpenAI Chat Completions API.""" | ||
| if content_block["source_type"] == "url": |
There was a problem hiding this comment.
This function references the old source_type field which has been removed in the refactor. This will cause a KeyError when called. The function needs to be updated to work with the new unified type system.
Copilot uses AI. Check for mistakes.
|
|
||
| Returns: | ||
| True if the content block is a data content block, False otherwise. | ||
| """ | ||
| try: | ||
| _ = _DataContentBlockAdapter.validate_python(content_block) | ||
| _DataAdapter.validate_python(block) | ||
| except ValidationError: | ||
| return False |
There was a problem hiding this comment.
If we return False or block.get("type") in ("audio", "image", "video)" and "source_type" in block, I believe we keep backwards compat.
block_typereplaces both oldtypeandsource_typefieldsblock_type, instead of bothtypeandsource_typeLiteralvalue inblock_typedirectly maps to exactly oneTypedDict.data:file:idchannel, you simplify adapters likeconvert_to_openai_data_block, and avoid boilerplate branching on media kindmime_typefield or introduce a new discriminator (e.g.data:image:id). But until there's a strong, real-world need to distinguish "ID for image" vs. "ID for audio," the singlefile:idvariant keeps the schema lean