[REQ][python] Allow type: number format: float to ingest json integers

[Marcelo00]

[REQ][python] Allow type: number format: float to ingest json integers

[spacether]

Can you please give an example schema and payload that is failing? Do you mean json schema number type with float as the format? With or without formatting?

[spacether]

Hmm I see that ingesting 0 is failing for format float and double ingestion.

>>> schemas.Float32Schema.validate(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/schemas.py", line 102, in validate
    return super().validate_base(arg, configuration=configuration)
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/schema.py", line 556, in validate_base
    path_to_schemas = cls.__get_path_to_schemas(cast_arg, validation_metadata, path_to_type)
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/schema.py", line 311, in __get_path_to_schemas
    other_path_to_schemas = cls._validate(arg, validation_metadata=validation_metadata)
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/validation.py", line 139, in _validate
    other_path_to_schemas = validator(
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/validation.py", line 288, in validate_types
    raise __get_type_error(
petstore_api.exceptions.ApiTypeError: Invalid type. Required value type is float and passed type was int at ['args[0]']

and

>>> schemas.Float64Schema.validate(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/schemas.py", line 102, in validate
    return super().validate_base(arg, configuration=configuration)
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/schema.py", line 556, in validate_base
    path_to_schemas = cls.__get_path_to_schemas(cast_arg, validation_metadata, path_to_type)
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/schema.py", line 311, in __get_path_to_schemas
    other_path_to_schemas = cls._validate(arg, validation_metadata=validation_metadata)
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/validation.py", line 139, in _validate
    other_path_to_schemas = validator(
  File "/Users/justinblack/programming/openapi-json-schema-generator/samples/client/petstore/python/venv/lib/python3.8/site-packages/petstore_api/schemas/validation.py", line 288, in validate_types
    raise __get_type_error(
petstore_api.exceptions.ApiTypeError: Invalid type. Required value type is float and passed type was int at ['args[0]']

And both the java and python generators impose this type constraint.

[spacether]

The openapi format registry defines float as:
single precision floating point number
And it defines format double as:
double precision floating point number
Why not define this data type as type: number with no format? That way serialization + deserialization will work.
Do you need the single precision min and max constraint applied?

My suspicion is that float and double formats should allow integers in by default because some language contexts (javascript) do not know the difference. One could add a command line option intsAllowedForFloatDoubleFormats to allow users to opt in or out of this behavior in the generated code. It would adjust the type definitions in that case.
I am asking for guidance from other implementers on this issue.

[Marcelo00]

Hmm I see that ingesting 0 is failing for format float and double ingestion.

We get the same error message in our use case.

The openapi format registry defines float as: single precision floating point number And it defines format double as: double precision floating point number Why not define this data type as type: number with no format? That way serialization + deserialization will work. Do you need the single precision min and max constraint applied?

Just using type: number will work as it includes integer values. The only problem we have is that we automatically create the openapi.yaml with TSOA which will by default set format: double. As the issue is more related to the behavior of TSOA and not primary to this repository, I created ticket on their side.

My suspicion is that float and double formats should allow integers in by default because some language contexts (javascript) do not know the difference. One could add a command line option intsAllowedForFloatDoubleFormats to allow users to opt in or out of this behavior in the generated code. It would adjust the type definitions in that case. I am asking for guidance from other implementers on this issue.

Independent of our problem, having such flag could give the user more flexibility but with a certain cost of adjusting the type definition as you said. Additionally, I could think of use cases where such flag is suitable and with making it optional, the default behavior will not change. The error message is still correct as ingesting a 0 where a float value is expected, should lead to a validation fail.

[spacether]

I just released version 4.3.0 which includes the command line arg --ints-allowed-for-float-double-formats
When one generates a client with it set to true, ints are allowed in to number with format float/double per:

>>> from unit_test_api.schemas import schemas
>>> schemas.Float32Schema.types
frozenset({<class 'float'>, <class 'int'>})
>>> schemas.Float32Schema.validate(0)
0
>>> schemas.Float64Schema.types
frozenset({<class 'float'>, <class 'int'>})
>>> schemas.Float64Schema.validate(0)
0

The value is defaulting to false right now to not break legacy code. In the next major release (5.0.0) I will change its default value to true so the defaults will allow normal json schema validation.

[Marcelo00]

Thanks for your work :)

[spacether]

You're welcome