Parameter names with '.' in them inconsistently generated into Python code

[haxsaw]

First off, nice tool: I do some swagger processing for a project of mine so I know the work involved.

So I tried swagger-to to generate Python on a client's swagger for one of their services, and while it ran without complaint, I noticed some of the generated code for a path was inconsistent between the parameter name vs the name used in the code. The problems centered on their use of parameter names that contain a '.' like the following:

"parameters": [
  {
    "name": "page.offset",
    "in": "query",
    "description": "Page offset"
    "required": false,
    "type": "string"
  },
  {
    "name": "filter.thing.like",
    "in": "query",
    "description": "wildcard filter",
    "required": false,
    "type": "string"
  }
]

The generated method for this path has parameters with names page_offset (note the underscore) and filter_thing_like. However, these parameters aren't used in the body of the code consistently; instead, the names as specified in the swagger are sometimes used, page.offset and filter.thing.like. Of course these names don't resolve so these methods don't work.

Here's an snippet from the incorrectly generated code:

        if filter.thing.like is not None:
            params['filter.thing.like'] = filter_thing_like

It seems the wrong object was referenced when generating the conditional for the if. The name used for the assignment is correct.

I have no idea if using a '.' in a name is legal as far as the swagger spec goes, but they're using it fine so I'm guessing it's ok. It appears that you've made some allowance for this as you transformed the '.' to '_' for the parameter names generated for the method definition. But it seems these transformed names aren't being used consistently in the body of the code. Since you have the proper translation around as evidenced by the parameter names I'm hoping it's a small change to output the correct version of the parameter in the body of the code.

[mristin]

Hi @haxsaw ! Thanks for reporting the issue! I will be able to look into this only in January 2024. If you have some time before, a pull request would be most welcome!

[mristin]

@haxsaw could you please confirm that the fix, which has been just merged into the master branch, fixes the issue on your side?

If so, then I'll release a patch version.

[haxsaw]

Hi @mristin ; it now appears to process the swagger I was trying properly. Good to go from my perspective. Thanks for the quick turnround.

[mristin]

@haxsaw I have just released a patch version and it should be uploaded to PyPI soon.