Integer values are not parsed correctly about odata-query

[OliverHofkens]

I just released v0.5 which includes this change!
Literal nodes now have a py_val property, which is the closest Python equivalent of the OData type.
I refactored the existing Transformers to use this new property as well.

Note that release 0.5 also includes full typing support, so keep that in mind if you use Mypy and upgrade.

Thanks for suggesting this!

[OliverHofkens]

Hey @keul ,
I think your example might be missing something as I don't see what you mean with SomethingElse.
The parser will always output an AST, and it's up to the ORM integration or a custom transormer to turn that into a usable query. So the Compare node you see is exactly what I'd expect for that query.

[keul]

Really sorry @OliverHofkens, opened the issue while rushing (SomethingElse was foo).

My question was about doing this:

>>> odata_filter.right
Integer(val='15')
>>> odata_filter.right.val
'15'

There's not an (easy) way to obtain the Python value expected from this token (so the 15 integer value and not the '15' str value).

I can obviously cast it myself by looking at the token type (Integer in this case) but I'm wondering if there's a more straightforward way.

[OliverHofkens]

Hey, no worries @keul, thanks for clarifying!

We could easily parse the values in Integers in the library. I think the only reason we didn't do this in the first place is because of consistency, as all other Token values are str as well. So if we're going to do this, I'd do this for all Token at once (Integer, Float, Boolean, Date, Time, DateTime, and Duration).

One thing we'd have to be absolutely sure about is that none of these casts result in data loss. The one that worries me most is Float, as the str value can hold arbitrary precise numbers while the Python float suffers from the classic floating point imprecision problems.

A foolproof solution would be to just add a @property to all Tokens that exposes the value as a Python built-in to end-users.

[keul]

Sure, I see the point!

Adding a new property getter with converted values would be great for a end-user point of view IMHO.