The changes in this file are just to cut out some test cases that I moved into test_unions.py, because ultimately the issue isn't about the enum itself, it's about the union type (created either explicitly with oneOf, or implicitly by adding "null" as an allowable type).

This was one of the cases affected by the bug. In the new version of this test that's in test_unions.py, the model class name is correctly rendered as MyEnumIncludingNull.

Just some nicer failure output. In a case like the one I mentioned above, where the generator has created an incorrect type name, if you try to import NameOfThing you'll see something like:

AssertionError: Couldn't find import "NameOfThing" in "testapi_client.models". Available imports in that module are: NameOfThingType0, SomeOtherType, [etc.]

An example of the effect that the bug was having on the reference code in the "golden record"-based tests, causing "Type0" and "_type_0" suffixes to be added for no good reason.

This is for a simple case where the schema is just like:

MyType:
 type: ["string", "integer"]

That's equivalent in meaning to anyOf: [{type: string}, {type: int}], so on lines 84-85 we convert it into those explicit variant types. However, if there was redundantly an anyOf or oneOf and a multiple type:, then we do not want to do that, because the variants that are described in the anyOf/oneOf list already fully describe the possible types. For instance:

MyType:
 type: ["string", "integer"]
 oneOf:
 - type: string
 format: date-time
 - type: integer
 default: 3

In that example, prior to my fix, the union would've ended up having four variants instead of two.

It took me a minute to really understand the logic of the two-pass loop in process_items

In addition to (or in place of) this comment block here, I think an example-based description of what this code is doing might be better.

Also, would it be possible to use some sort of lookup to track the schema, and then the single name schema gets updated at the end of the loop if only one named schema was encountered 🤔
I'm not sure if that will be necessarily easier/shorted to read than the current implementation but I think the two loops is more on the less-trivial scale.

Also, would it be possible to use some sort of lookup to track the schema, and then the single name schema gets updated at the end of the loop if only one named schema was encountered

Unfortunately no, that's not possible. I mentioned the reason for this when we talked, but I should clarify it in the comment too: there are maps in schemas that already contain references to the processed classes by name, so we can't just modify one object in place.

ahhh yes, I remember you mentioning it, but I think I hadn't grokked the code enough to fully understand.