OpenAPITools / OpenAPITools/openapi-generator

[REQ] Add Support for enumUnknownDefaultCase in Python Generator

Open
#20,012 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Enhancement: Feature
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

Is your feature request related to a problem? Please describe.

The base python generator does not currently appear to support the enumUnknownDefaultCase configuration. I'm unsure if this represents a bug report or feature request, specifically because this configuration is documented on the base OpenAPI generator docs here (which I presume would be supported by all generators). This feature allows the generated client to default to a standard unknown value of unknown_default_open_api when the API introduces new or unexpected enum values, thus preventing enum additions or alterations from breaking older generated clients.

I noticed this configuration is supported in other Python generators, such as python-flask, python-blueplanet, and python-aiohttp. However, its absence in the main Python generator requires users to create less than ideal workarounds for maintaining compatibility with new enum values.

Describe the solution you'd like

I would like the Python generator to support the enumUnknownDefaultCase configuration so that it automatically assigns a default value whenever an unknown enum value is encountered. This would allow Python clients generated from OpenAPI specs to handle enum extensions more gracefully.

Describe alternatives you've considered

  1. Changing enums to string types in our OpenAPI spec, allowing unknown values to be interpreted as raw strings rather than enums. This avoids errors for unexpected values but sacrifices the type safety and clarity that enums provide.

  2. Setting _check_return_type() to False on requests when using the generated SDK, which bypasses type checks for responses. While this method allows unknown values, it also disables type checking for all response fields, potentially allowing unintended data to pass through unchecked.

  3. Specifying existing enum types with an anyOf combination that includes both the enum and {} (an empty schema), which permits unknown values by allowing any object to satisfy the type check. However, this approach is less clear and increases complexity in our OpenAPI spec, making it harder to interpret and maintain.

Additional context

N/A

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing the base Python generator with the Python generators named in the issue, including python-flask, python-blueplanet, and python-aiohttp, and review the enumUnknownDefaultCase documentation. Trace how generated Python clients handle enum values and verify the change with the generator's existing tests or a generated client that receives an unknown enum value.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, devtools
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.