Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dividing a tomlkit.Integer by an int does integer division, instead of 'true' division #309

Closed
anthrotype opened this issue Aug 4, 2023 · 1 comment

Comments

@anthrotype
Copy link

Something is up with the tomlkit wrapper for built-in int type. Using the / division operator between integers in python 3 should use __truediv__ and thus return a float, not an int... But if I divide a tomlkit Integer with another int, I get an int, as if it were truncated or doing integer division (//). I don't know why...

>>> from tomlkit.items import item, Integer
>>> i = item(1)
>>> assert type(i) is Integer
>>> v = i / 2
>>> assert type(v) is Integer  # should it not be a float?!
>>> print(v)  # that's wrong, should be 0.5
0
>>> assert v == 0.5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError

And if one attempts to extract a float from this tomlkit Integer, one gets a very weird error deep from the numbers module which makes no sense to me:

>>> float(v)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/google/home/clupo/.linuxbrew/lib/python3.11/numbers.py", line 381, in __float__
    return float(int(self))
                 ^^^^^^^^^
TypeError: __int__ returned non-int (type float)

If I unwrap this weird v.unwrap()... I get the float back, 0.5 ...
It's like after truediv the Integer wrapper is in fact wrapping a float.
This makes tomlkit entirely unusable for us as we can't no longer trust that an int is an int and a float a float.

@anibali
Copy link
Contributor

anibali commented Sep 20, 2023

This is quite a big issue, we've had to downgrade to tomlkit 0.11.8 as a workaround. After some brief investigation I believe that the issue was introduced in 0.12.0 with this PR: #307

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants