naturalsize() contains a very common but serious programming bug

[Arcitec]

I just finished writing a proper "human bytes" function. When I was done, I did a Google search and actually found this project but noticed that you have the same major bug that the majority of other programmers in the world have. Since you've created a library that people reuse, it's important that you fix the bug in the library.

Here's the bugged library file:

https://github.com/jmoiron/humanize/blob/e2b217f2407a4f16b99516caf8934a12b16d58de/src/humanize/filesize.py

Here's the code I posted on a throwaway stackoverflow account. It explains the bug and provides a solution. You can pick it apart and adapt it for your project. Good luck! :-)

https://stackoverflow.com/a/63839503/8874388

[facundobatista]

In which case are you finding a issue in the library?

Your post opens with the rounding problem but it seems to work fine in the lib:

>>> humanize.naturalsize(1023.59)
'1.0 kB'

Thanks!

[samueljsb]

If we're looking at binary sized (where the base is 1024) we never get anything like '1024.0 Bytes'.

The value is truncated, rather then being rounded, so you get something slightly surprising at the limit:

>>> import humanize
>>> humanize.naturalsize(1023.9999999999999, binary=True)
'1023 Bytes'
>>> humanize.naturalsize(1023.99999999999999, binary=True)
'1.0 KiB'

That looks like a different problem from the one that StackOverflow post describes though (if it's a problem at all – I'm not sure if it is).

[facundobatista]

Thanks @samueljsb! I just confirmed this weird behaviour in v3.13.1.

[hugovk]

🚀 Development has moved to https://github.com/python-humanize/humanize 🚀

Please open new issues at https://github.com/python-humanize/humanize/issues