[BUG] anyOf not properly translating python unions

[jprince14]

Description

The Python client typing for anyOf if not properly generating python Unions when there are two or more (non-None) types in the anyOf

openapi-generator version

openapi-generator-cli version 7.14.0

OpenAPI declaration file content or url

Original Python Code used to generate the OpenAPI spec

class TestModel(BaseModel):
    three_types: int | str | bool
    two_types_plus_none: str | int | None
    two_types: int | str
    one_type_plus_none: int | None

OpenAPI Model

Full Model is in the Gist https://gist.github.com/jprince14/fd0f215c78a4a387762df9617f1f4b80

Snippet of the model

"TestModel": {
    "properties": {
        "three_types": {
            "anyOf": [
                {
                    "type": "integer"
                },
                {
                    "type": "string"
                },
                {
                    "type": "boolean"
                }
            ],

Python model generated by openapi-generator-cli

Python Client Gist https://gist.github.com/jprince14/ca6fb39a6133b5fc96683dbffc70f22e

Snippet of generated python client

class TestModel(BaseModel):
    """
    TestModel
    """ # noqa: E501
    three_types: ThreeTypes
    two_types_plus_none: Optional[TwoTypesPlusNone]
    two_types: TwoTypes
    one_type_plus_none: Optional[StrictInt]

Generation Details

openapi-generator-cli generate -i openapi.json -g python

Steps to reproduce

Generate the python client

Related issues/PRs

I didn't see anything

Suggest a fix

Using three_types as an example, if the OpenAPI json is an anyOf(integer OR string OR boolean) why not make the python client type str|int|bool. Creating a pydantic model for three_types does not seem optimal

[Mark90]

We also noticed this. What would be the expected generated client you think?

I wonder if this was intended behavior given that pydantic recommends against using Union[]

In general, we recommend using discriminated unions. They are both more performant and more predictable than untagged unions, as they allow you to control which member of the union to validate against.

But pydantic still supports Union[], so that doesn't seem to be the reason