Eli Bishop

It's hard to be sure without seeing the actual spec, but based on the error output there, I think the problem is that the generator currently just doesn't support specifying...

My guess is that this would be a medium-size fix to implement in a simple way where it would _not_ try to validate the dict value in any detail at...

Here's a case where I'm not 100% sure what the behavior should be: ```yaml components: schemas: ModelA: type: object properties: modelType: type: string ModelB: type: object properties: modelType: type: string...

Putting this back to draft because I have a couple ideas to simplify/clarify things.

OK, I pushed some more changes to simplify things a bit. There was some extra validation that I could add in a follow-up PR, which I don't think is essential...

I had submitted https://github.com/openapi-generators/openapi-python-client/pull/1095 before seeing that this fixes the same issue. I've closed mine, but it did include one other change that I think might be good to add...

Also, if I understand correctly, the only reason this PR is flagged as "breaking" is the change to the prefix logic (VALUE_, LITERAL_). I agree with the rationale behind that...

@expobrain: > about having a config to handle the new enum behaviour and avoid breaking changes, I've already added this in the ConfigFile here I see the new config option,...

And... at the risk of being nitpicky and overthinking things, I do have some other thoughts about the VALUE_ vs. LITERAL_ thing. First, I do think that it should be...

> Superceded by https://github.com/openapi-generators/openapi-python-client/pull/1114, which I think will add enough flexibility for anyone who needs it How to judge "enough flexibility" is subjective of course, but for what it's worth,...