Skip to content

Conversation

@NeejWeej
Copy link
Collaborator

@NeejWeej NeejWeej commented Mar 6, 2025

fixes #475

@NeejWeej NeejWeej force-pushed the nk/ast_fix branch 2 times, most recently from 235f6a0 to 902f3ce Compare March 7, 2025 01:03
@NeejWeej NeejWeej marked this pull request as draft March 7, 2025 06:01
@classmethod
def from_dict(cls, json: dict):
def from_dict(cls, json: dict, use_pydantic: bool = False):
if use_pydantic:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Rather than an arg can we base this on whether we are using pydantic type checking ( which defaults to true now )?
My only concern is speed. If we can do some timing tests and pydantic is as fast as the current code, I would just default it to use pydantic ( and eventually remove the old impl )

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The old way is a bit permissive and there will be some inconsistencies that might be annoying to fix, so I figured itd be easier to make it a flag for now. But eventually would like to switch to pydantic if its performant enough

return cls.type_adapter().validate_python(json)
return cls._obj_from_python(json, cls)

def to_dict_depr(self):
Copy link
Collaborator

Choose a reason for hiding this comment

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

should we have an equivalent pydantic to_dict?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

sure!

Copy link
Collaborator

@arhamchopra arhamchopra Mar 7, 2025

Choose a reason for hiding this comment

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

@robambalu Should we just remove to_dict_depr now?

return cls._NORMALIZED_TYPE_MAPPING.get(CspTypingUtils.get_origin(typ), typ)
elif CspTypingUtils.is_union_type(typ):
return object
elif CspTypingUtils.is_literal_type(typ):
Copy link
Collaborator

Choose a reason for hiding this comment

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

I realize we just moved code here, but looks like we can probably use normalized_type_to_actual_python_type here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

But literal takes instances of types, not types

(so like Literal[7] versus Literal[int]) and normalized_type_to_actual_python_type doesnt seem to actually pull the true base class out except in this case for Literal

@timkpaine timkpaine added the type: bug Concrete, reproducible bugs label Mar 7, 2025
@NeejWeej NeejWeej closed this Mar 7, 2025
@NeejWeej
Copy link
Collaborator Author

NeejWeej commented Mar 7, 2025

THis PR has been split into 2 different ones for clarity, please check those instead:

#478
#479

@timkpaine timkpaine deleted the nk/ast_fix branch April 21, 2025 19:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: bug Concrete, reproducible bugs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Handle unions via | with None properly

6 participants