[BUG] [PYTHON] additionalProperties not supported

[ivan-gomes]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Bounty to sponsor the fix (example)

Description

Generated Python clients do not have the ability to access the additional properties of models with additionalProperties defined. The only ones that can be accessed are those that are explicitly defined in the model and the rest are ignored. In contrast, the generated Java models extend HashMap when additionalProperties are defined and they can get accessed by Map#get(String).

openapi-generator version

4.0.0

OpenAPI declaration file content or url

  Element:
    type: "object"
    required:
    - "id"
    properties:
      id:
        type: "string"
      name:
        type: "string"
    additionalProperties:
      type: "object"

Full specification: https://github.com/Open-MBEE/mms/blob/develop/mms-ent/repo-amp/src/main/amp/web/mms/mms.swagger.yaml

Command line used for generation

java -jar /path/to/openapi-generator-cli.jar generate -i /path/to/mms.swagger.yaml -l python -o ~/tmp

Steps to reproduce

Inspecting the generated Element.py file after executing the command above with the specification above. There is also a usage of additionalProperties in the Petstore API that exhibits the same behavior.

Related issues/PRs

Clone of issue made and fixed in swagger-api/swagger-codegen: swagger-api/swagger-codegen#8075

Suggest a fix

I believe that the additional properties can be stored in a dict, analogously to how they are handled in Java.

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[spacether]

This feature was added in #4154

[j--wong]

Hi,

I just wanna double check, so to use the additionalProperties support, do I need to use python experimental generator -g python-experimental instead of python -g python?

Thanks,
Josh

[spacether]

Yes, that's right

[j--wong]

Yes, that's right

Thanks @spacether .. is there any documentation on the difference between python and python-experimental generators? When do those experimental features become stable? And when they become stable, do they get migrated to python generator?

We are already using python code generated by python generator. We also need additionalProperties support. So thinking whether or not to switch to python-experimental to get that feature or to wait for it to become available in python generator.

The other issue that might prevent us to move to python-experimental is, upon trying it out, I noticed the generated code is drastically different from the ones from python. I am suspecting it won't be backward compatible?

Thank you and much appreciated for your reply!

[spacether]

The interfaces are very similar in python and python-experimental so switching from one to the other should be pretty straightforward.
Feature additions from python-experimental are not migrated to python. We don't have the manpower to do it and as you said they are structured a bit differently.

is there any documentation on the difference between python and python-experimental generators

Not at this time. I have listed out some of the significant new features below.

Breaking changes are allowed to python-experimental and one can peg the openapi version that you are using to stay with one that you like.
Significant advancements have been made in python-experimental including:

• data types stored as actual class references, not strings
• additionalProperties support
• type + validation checking when instantiating a model, sending data to an endpoint, and receiving data from an endpoint
• composed schema support (oneOf/anyOf/allOf)
  • openapi (v3) type null support in oneOf schemas
  • support for oneOf with mixed types (object, array, str, null etc..)
• stronger discriminator support (a payload can be deserialized using n different discriminator propertyNames)
• python-experimental is in python3 only, and includes some type hints
• module load times have been expedited by not loading all models when the root package is imported
• models are made for non-object schemas with validations
• support for http signature security schemes

In the near future python-experimental will become the main python generator.
We do not have a firm schedule on it.

[j--wong]

@spacether sounds like we would eventually need to move to python-experimental at some point.

Would you recommend production apps using experimental generator right now? The word experimental would scare a lot of people away from adoption for prod. 😅 Also, would you say allowing breaking changes mean not suitable for production apps at this stage?