Inconsistent behavior when validating number, float, and int

[jnichols0]

In version 1.8.0, given a schema like so:

mapping: 
  something:
     type: number

the following yaml is valid:

something: "1"

This seems to also be the case where "something" requires type float. However the yaml isn't valid when "something" requires type int. I saw in type.py that is_int returns True when an obj is an int object and not a boolean. However is_float returns True when an obj is a float or when that obj can t be successfully cast to a float. Why not check if the obj can be cast to an int to determine if it's an int? I am wondering if this seeming inconsistency is purposeful. I am not terribly familiar with kwalify outside of use of this library. It just seems so odd that the string literal "1" is a valid float and number, but not integer.

My environment:
CPython 3.7.9 and 3.8.5
pykwalify 1.8.0

[Grokzen]

@jnichols0 Hmm, i guess this is something where there might be some inconsistency between the original specification from kwalify and how i interpreted it and implemented it. From the specification you find this

float
number (== int or float)
text (== str or number)

But what i am going to say is that i think i have implemented the specification right based on the original source code and how it worked over in ruby, but i do get your point about the inconsistency and i kinda agree with that point as well. So what we got here then in the end is that how we should fulfill both the specifications but also update it to make it both compatible and logical in a python context.

So if we say that we make it so a int is attempted to be converted before checking then we get into some strange cases as well because how do you then define or trust that in some cases all you really want to check is isinstance(obj, int) and not care if it is a string that can be converted into it as you want that check alone and not accept a int value inside a string. Then you would break that check if you add in the implicit string convert. Yes you can already argue that is the case with float now and that might need to change from a opt-out to opt-in solution with a parameter to the float types and number type for example. But floats do have that other special notation of 1e-06 that is a string repr of float that needs to be converted to be valid.

[jnichols0]

Thanks for the reply. I hadn't considered the 1e-06 notation.

I did check bot the Ruby and Java implementations to see how they handle this. Both fail validation on my example schema and document in my first post. I didn't check the source code but I am betting they do not try to cast to float to verify it something is a float. I don't know where to find the official kwalify spec but I figured I'd let you know what I found for these reference implementations.

I think for my usage I'll have to just add a custom validator function to disallow strings as numbers, floats, or ints.