You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The output should be sanitized in some way. Python's str.isidentifier can help, and the output could be prefixed by _ (although that could appear to be private, and thus confusing), or __, or field_, or something else.
In our manually-written clients, we replace it with one_q and two_q, but that's not generally applicable in openapi-python-client (for reasons to include internationalization and maintaining semantic meaning)
As it stands now, this requires manual correction after generation. If the intent is (eventually) to support all valid OpenAPI schemas, then this would have to be addressed at some point.
Desktop (please complete the following information):
OS: OSX 10.15.6
Python Version: 3.7.3
openapi-python-client version: 0.6.1
Thanks! Happy to send a PR for it.
The text was updated successfully, but these errors were encountered:
Thanks @kalzoo, this is definitely something we should address. I do like the field_ option better to avoid the Python private syntax. If you want to take a crack at it, I'd be happy to accept a PR. I believe this would just be some additional sanitization on parser.properties.Property.python_name
Thanks for the report and the fix for this @kalzoo! It'll be in the next release (0.6.2). My plan is to wait until a couple more things are complete before doing a release, but if you need this soon just let me know and I'll put the release together sooner.
Describe the bug
Schema fields may generate client models which contain invalid identifiers.
Example
generates a class which is invalid Python:
Expected behavior
The output should be sanitized in some way. Python's
str.isidentifier
can help, and the output could be prefixed by_
(although that could appear to be private, and thus confusing), or__
, orfield_
, or something else.In our manually-written clients, we replace it with
one_q
andtwo_q
, but that's not generally applicable inopenapi-python-client
(for reasons to include internationalization and maintaining semantic meaning)As it stands now, this requires manual correction after generation. If the intent is (eventually) to support all valid OpenAPI schemas, then this would have to be addressed at some point.
Desktop (please complete the following information):
Thanks! Happy to send a PR for it.
The text was updated successfully, but these errors were encountered: