Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

union types and nullables can create unnecessary class suffixes (and related problems)

Open
#1,120 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
openapi, python
Domain
devtools

Research direction

Start with the UnionProperty behavior and generate clients from the linked OpenAPI 3.0 and 3.1 spec files. Compare the generated class names and duplicate models with the examples described in the issue. Done means nullable and union schemas no longer receive unnecessary suffixes or create identical extra classes.

Written by the indexing model from the issue text.

Description

Describe the bug
In some valid specs, the use of anyOf, oneOf, nullable, and/or type as a list, can cause generated class names to have unnecessary suffixes (and, sometimes, for spurious extra copies of classes to appear). These problems seem to all ultimately come from the behavior of UnionProperty.

The problem cases are all included in the attached specs files. Looking at the code generated from these specs—

in both 3.0 & 3.1:

  • ExampleModel.nullableObjectWithOneOf correctly has the type Union[MyObject, None, Unset].
  • ExampleModel.inlineNullableObject generates a model class called ExampleModelInlineNullableObjectType0. It should be just ExampleModelInlineNullableObject, since there are no other named types for this property.
  • Similarly, the MyEnum schema, which is a nullable enum, generates the class MyEnumType1 even though there is no Type0.
  • The MyEnumWithExplicitType schema is the same as MyEnum except it specifically indicates type, and the result is a bit wilder: it generates enum classes MyEnumWithExplicitTypeType1, MyEnumWithExplicitType2Type1, and MyEnumWithExplicitType3Type1, all of which are exactly the same.

only applicable to 3.1:

  • ExampleModel.nullableObjectWithExplicitTypes, which is the same as nullable_object_with_one_of except that it also (unnecessarily, but validly) specifies type: ["object", "null"], also works correctly.
  • ExampleModel.one_of_enums_with_explicit_types, which combines a string enum with an int enum and specifies `type: ["string", "integer"], has the problem where three classes are created for each enum.

OpenAPI Spec Files
3.0: https://gist.github.com/eli-bl/7bea406525fb3b1452a71781ada5c1c0
3.1: https://gist.github.com/eli-bl/c03c88eb69312053e0122d1d8a06c2a0

Desktop (please complete the following information):

  • OS: macOS 14.5
  • Python Version: 3.8.15
  • openapi-python-client version 0.21.5
Dominant language
Python
Stars
2k
Forks
293
Avg merge
34m
Merged PRs (30d)
1

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.

More from openapi-generators/openapi-python-client

All issues in openapi-generators/openapi-python-client

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.