[BUG] [Python] Attribute Names are not Validated or Converted when Creating Models

[ckoegel]

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?
• 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

Generated python models currently accept attributes with any name in their initialization, which allows for objects to be created with attributes that do not match their attribute map. There is also no attempt to convert attributes to their corresponding names in the attribute map. This can lead to issues with reserved words if a dictionary with a reserved word as a key is used to initialize the object. An example is shown below.

Model Attributes:

class Message(ModelNormal):
        # some code
        attribute_map = {
                'application_id': 'applicationId',  # noqa: E501
                'to': 'to',  # noqa: E501
                '_from': 'from',  # noqa: E501
            }
        # some code

Input:

message_body = {
        "applicationId":"app-abcd",
        "to":"+19195551234",
        "from":"+19195554321",
        "does_not_exist":"fake attribute"
}
new_message = Message(**message_body)
print(new_message)

Expected Output:

{'application_id': 'app-abcd', 'to': '+19195551234', '_from': '+19195554321'}
# Some error mentioning does_not_exist as an invalid and unconvertable attribute

Actual Output

{'applicationId': 'app-abcd', 'to': '+19195551234', 'from': '+19195554321', 'does_not_exist': 'fake attribute'}

This Actual Output is problematic because attempting to access the from attribute is impossible since it cannot be referenced with new_message._from or new_message.from since it was not converted and from is a reserved word. The does_not_exist attribute also should not be created since it does not exist as a valid attribute of the Message object.

openapi-generator version

0.5.3

OpenAPI declaration file content or url

https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/python/model_utils.mustache
https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/python/model_templates/method_from_openapi_data_normal.mustache
https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/python/model_templates/method_init_normal.mustache

Generation Details

using the spec at https://github.com/Bandwidth/api-docs/blob/main/site/specs-source/messaging.json and generating using openapi-generator-cli generate -g python -i messaging.json -o ./msg-test allows for viewing the generated SDK.

Steps to reproduce

Using the SDK generated above, attempting to create a BandwidthMessage object with different combinations of valid and invalid attributes reproduces the different errors.

Related issues/PRs

Indirectly relates to #11092 and #11125, since they allow for more methods of object creation.

Suggest a fix

Adding logic to the set_attribute function within model_utils.mustache should allow for this to be fixed. I'll be opening a PR shortly and linking it here with my solution. PR is #11134

[spacether]

@ckoegel we use separate interfaces for using javascript/spec named inputs and using python named inputs.
When you use the interface that processes javascript/spec named inputs they are converted.
MyModel.__new__ which is used with code like MyModel(some_val=1) uses python named inputs and is for instantiation client side using python naming.
MyModel._new_from_openapi_data() uses the javascript/spec named inputs
So this is a feature, not a bug.
Can you please load in your payload with the message = Message._new_from_openapi_data() method?

[spacether]

The does_not_exist attribute also should not be created since it does not exist as a valid attribute of the Message object

That's not how openapi works. If you did not define additionalProperties: false in your type object schema, then any additional property that is passed in as a payload is accepted and validated as part of that payload. So the does_not_exist property should be accepted and kept in the model instance.

One can read all about it in the docs here: http://json-schema.org/understanding-json-schema/reference/object.html#additional-properties

[spacether]

Your code assumes that python models by default use spec property naming which they do not.
To use spec property naming, one can instantiate models with spec property naming like Model(someArg='blah', _spec_property_naming=True) see this example here

[ckoegel]

@spacether

@ckoegel we use separate interfaces for using javascript/spec named inputs and using python named inputs. When you use the interface that processes javascript/spec named inputs they are converted. MyModel.__new__ which is used with code like MyModel(some_val=1) uses python named inputs and is for instantiation client side using python naming. MyModel._new_from_openapi_data() uses the javascript/spec named inputs So this is a feature, not a bug. Can you please load in your payload with the message = Message._new_from_openapi_data() method?

Using the Message._new_from_openapi_data() does not appear to cause these inputs to be converted. Based on your most recent comment, I would assume that _spec_property_naming for this function would default to true, but just like the __new__ function, it defaults to False. Adding _spec_property_naming=True to the object initialization seems to solve the issue, regardless of whether or not _new_from_openapi_data is used. Should _spec_property_naming default to True for the
_from_openapi_data function?

[spacether]

Should _spec_property_naming default to True for the
_from_openapi_data function?

Yes it should

[ckoegel]

Should I change my PR to default that to true since the functionality is similar? Or should I make a new PR for that?

[spacether]

How about you include it in your existing PR. Thanks!

[ckoegel]

Sounds good, thank you!

[spacether]

Closing this because property names are validated per spec in python v6.2.0 and onward