Connexion: Convert camelcased parameter names to Python style convention

[jrc]

Description

It's common to define Swagger parameter names in camelcase ("postalCode", "modifiedDate", "statusCode", etc.), but this goes against Python PEP-8 convention.

Expected behaviour

From Swagger:

get:
  parameters:
    - name: postalCode
      in: query
      type: string

I would like to be able to write

def search(postal_code, ...):
    ...

Actual behaviour

The parameters are not found:

TypeError: search() missing 1 required positional argument: 'postal_code'

Additional info:

Output of the commands:

$ python --version
Python 3.5.2
$ pip show connexion | grep "^Version\:"
Version: 1.0.129

Here's a regex for the conversion: http://stackoverflow.com/a/1176023/594211

[hjacobs]

Regarding it's "common", we (in Zalando Tech) agreed on having snake_case JSON properties and parameters: http://zalando.github.io/restful-api-guidelines/naming/Naming.html

But I agree that the conversion would be useful for people with a different convention.

[danballance]

Hi,

We use camelCase for all of our API/Swagger definition, path and query names and then I convert to snake_case at the entry point to the python application. If there was an option to switch on that let Connexion do this for me, that would be really cool!

One thing I have also been doing is adding an underscore at the end for shadowed variables - the most common example being translating id to id_. What do folks think about some kind of automated shadowing support as well?

[rafaelcaricio]

I agree that this is an important feature for Connexion to support by default. Regarding translating responses to camelCase, then it should be an option. But the parameters should be always translated to the "Pythonic" manner (snake_case, builtins shadowed).

[danballance]

Okay great, I might be able to take a look at this quite soon. I'll submit a PR if I can manage to get the work done.

[danballance]

I noticed reading in the Stack Overflow thread above that there is a library we could use instead of the proposed regex:

http://inflection.readthedocs.io/en/latest/#inflection.underscore

This seems a more resilient approach to me, in that any bugs or enhancements will get included in that library over time. By contrast our regex will not change unless we update it. Obviously the downside is adding another dependency to the project. Personally I'm okay with the additional dependency. Is there anyone against me including this library?

[rafaelcaricio]

@danballance I am ok with that.

[danballance]

I've finally got some time to look at this.

I'm thinking I will probably make a change in decorators.parameter.parameter_to_arg. I'll update here if the plan changes.

[danballance]

I'm not sure if anyone will have time to reply on this, but I have a working solution locally that I'm currently writing unit tests for. I just wanted to check, but since in many scenarios this will be a non-backwards compatible change and would break existing code, I'm working on the basis that the default behaviour is not to modify parameter names unless a boolean option is passed as True.

[rafaelcaricio]

@danballance Yes, please keep the current behaviour as the default one. You can add a flag to enable the possibility of translating.