Linting error when class has a property with the same name after snake case

openapi-python-client: 0.21.4
Python: 3.10
OpenAPI spec version: 3.0.3

In OpenAPI specs where a property has the same name as the snake cased class name (in the example below, the snake casing is the lower case, but if it was, ex, InstagramId, then this would happen with a property named instagram_id) the code generated has a duplicated variable name (see image below).

The suggested fix is that the return variable name should have an underscore _, in this example, email_.

      "Email": {
        "type": "object",
        "properties": {
          "email": {
            "type": "string"
          },
          "verified": {
            "type": "boolean"
          }
        },
        "required": [
          "email",
          "type"
        ]
      },

Monosnap xeal-qa-utils – email py 2024-09-03 18-31-37

Note: I understand that openapi-python-client uses ruff, but I also use mypy on the autogenerated code as it's part of a greater CI/CD workflow.

Another option would be to change the name we use for the temporary value that's eventually returned, that way the property can keep its normal name.

The challenge will be picking a name that is unlikely to be used as a property. I suppose _email, since we try to avoid generating "private" names for properties?

This is an external API that I'm consuming so I can't really change the name of the property. I can, however, change the name of the class, which I changed to EmailObj.
But this is a temporary solution. The code should be fixed, imo.
The return variable name could be named return_obj, _return, obj, value or something neutral like that.

Seems to me like the only reason there's a variable name at all in that last part is that additional_properties needs to be set separately— it's been deliberately declared as not settable via the initializer (which also makes it not settable by evolve), for reasons I'm unclear on. Otherwise it could just be:

return cls(
    email=email,
    verified=verified,
    type=type,
    id=id,
    additional_properties=d
)

@dbanty

Seems to me like the only reason there's a variable name at all in that last part is that additional_properties needs to be set separately— it's been deliberately declared as not settable via the initializer (which also makes it not settable by evolve), for reasons I'm unclear on. Otherwise it could just be:

return cls(
email=email,
verified=verified,
type=type,
id=id,
additional_properties=d
)

I'm having the same issue. For now, I've just replaced {% module_name %} with {% module_name %}_obj in a custom template to avoid the mypy error, but your approach looks cleaner to me.

@dbanty Is there a reason why additional_properties cannot be set during initialisation? If not, I could implement this and open a PR.

@micha91

Is there a reason why additional_properties cannot be set during initialisation? If not, I could implement this and open a PR.

@micha91 not that I remember 😅 so feel free to make a PR for it. Should be a pretty small change I think!

Navigation Menu

Repository navigation

Linting error when class has a property with the same name after snake case #1117

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Linting error when class has a property with the same name after snake case #1117

Description

Activity

joaonc commented on Sep 3, 2024

dbanty commented on Sep 4, 2024

joaonc commented on Sep 4, 2024

eli-bl commented on Nov 5, 2024

micha91 commented on Jul 1, 2025

dbanty commented on Jul 3, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions