bits_to_name `decimal` handling seems odd

[glennmatthews]

Environment

• Python version: 3.9.7
• netutils version: 1.0.0

Expected Behavior

>>> bits_to_name(1234)
'1Kbps'
>>> bits_to_name(1234, 1)
'1.2Kbps'
>>> bits_to_name(1234, 2)
'1.23Kbps'
>>> bits_to_name(1234, 3)
'1.234Kbps'
>>> bits_to_name(1234, 4)
'1.2340Kbps'

Observed Behavior

>>> bits_to_name(1234)    # expect 0 decimal places, instead get 1 decimal place but it's wrong!
'1.0Kbps'
>>> bits_to_name(1234, 1)
'1.2Kbps'
>>> bits_to_name(1234, 2)
'1.23Kbps'
>>> bits_to_name(1234, 3)
'1.234Kbps'
>>> bits_to_name(1234, 4)  # expect 4 decimal places, instead still get 3 since the fourth is zero
'1.234Kbps'

[jdrew82]

I observed this during testing I think. It's something with the way that round works I think.

[itdependsnetworks]

@jdrew82 then perhaps using round is not the correct strategy or using round requires some post processing?

[jdrew82]

Actually, now that I think about it, I think the problem is that it's a float. Because it's a float the string rep of it includes the .0 portion. We'd need to format it to remove it.

[jdrew82]

The issue appears to be that it will show the .0 if you specify the decimal point in round to be 0. If you don't specify it at all it doesn't include it. I've got a PR coming in with a tweak to address this quirk.