Invalid Schema of String and Boolean

[gauravk-mk]

Currently, there is an issue with the string and boolean schema in Colander. The schema does not handle invalid values correctly and leads to unexpected behaviour.
When a string or boolean value is passed to the schema, it should only accept valid values that match the specified format or type. However, the current implementation allows invalid values to be accepted without any warnings or error messages. This can cause issues when processing the data later on, as the data may not be in the expected format.
For example, if a boolean schema is defined to only accept "true" or "false" values, but an invalid value such as "1" or "yes" is passed to the schema, the schema should raise an error. However, the current implementation accepts these invalid values without raising any errors, which can lead to unexpected behaviour in the code.
And if String schema is defined, it accepts all the data types at the time of serialisation and converts them to a string which shouldn't happen while validating.
This issue can be problematic for developers who rely on Colander for data validation, as it can lead to data integrity issues and difficult-to-debug errors. It is important to ensure that the schema correctly handles invalid values and raises appropriate error messages to alert developers to potential issues.
Overall, the issue with invalid string and boolean schema in Colander needs to be addressed to ensure that the schema is reliable and can be trusted for data validation.

[Navy078]

Yes I'm facing same Issue

[mmerickel]

Hey folks, type coercion is a feature of colander, not a bug. This is common with many (de)serialization frameworks - they are not directly responsible for validation. You can think of colander more similarly to str(x) where it is asked to serialize "something" to a string, or similarly deserialize "something" into a number such as float('5.0').

Colander can be extended to support more strict type validation for certain use-cases but it is not builtin to the default types. One example that could be built upon is you'll notice that colander.Integer supports a strict=True that will error if the value being (de)serialized is not exactly an integer type. It's worth noting in that scenario it will still accept a float that looks like an int, such as 5.0.

I have no plans to work on this feature myself, but would try to find time to consider any contributions and review them.