Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists? (tested with 5.0.0-20201027.153630-833, still exists)
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

PythonCodegen when run against https://emergin.informer.io/api/openapi.json will produce the literal string null in the tests. This is accompanied by the warning:

[main] WARN  o.o.c.languages.PythonClientCodegen - Type null not handled properly in toExampleValue 

These values can sometimes be replaced with the literal None however in other cases they should be generated recursively.

openapi-generator version

4.3.1

OpenAPI declaration file content or url

https://emergin.informer.io/api/openapi.json

Generation Details

openapi-generator-cli generate --generator-name python --input-spec https://emergin.informer.io/api/openapi.json

Steps to reproduce

1. Generate the client using the command above
2. Run the tests with pytest

You will observe that 7 tests fail and 53 pass.
The errors are NameError: name 'null' is not defined.

3. Substitute all null for None using the tool of your choice (my choice: sed -i -e s/null/None/ test/*.py)
4. Run the tests with pytest

You will observe that 4 tests fail and 56 pass.
The errors are now ValueError: Invalid value for results, must not be None

Related issues/PRs

I cannot find any occurrence of this error message in these issues, open or closed.

Suggest a fix

So the code generation is capable of handling null, as we can see here. I don't understand why it tests that the example output is not the literal null as the code immediately following the warning will just return it.

It might be possible to address some of the incorrect code generation by dropping the comparison to null on line 724, linked above.

I don't know why the recursive type is not handled correctly.