Sometimes you want a fixed number of characters to be used for a number (for logging for example).

With 5 characters (this includes numbers, decimal points and magnitude):

4000000 => 4.00M
40000   => 40.0K
4000    => 4.00K
400     => 0.40K (400 and 400.0 are wrong as they take 3 and 5 places)
40      => 0.04K or 40.00
4       => 4.000

The function prettify has a self-loop, but it doesn't account for a different character in the loop it just affects the first iteration. This is the solution to the error.

def prettify(amount, separator=','): """Separate with predefined separator.""" orig = str(amount) new = re.sub("^(-?\d+)(\d{3})", "\g<1>{0}\g<2>".format(separator), str(amount)) if orig == new: return new else: return prettify(new, separator)

prettify was only using the custom separator once, then all latter separators defaulted to comma. reproducible with long numbers, e.g. prettify(1000000000, "-") -> '1,000,000-000'

The code in this PR is build on top of @weefatboi's work (#2). tests\test_millify.py now contains unit tests that test the fix by @weefatboi, and the existing code. Based on the tests, three changes are made to __init__.py:

• Only use custom prefixes if a list is passed;
• Only use a custom separator if a string is passed;
• For numbers with more than five digits that were passed to prettify() with a custom separator, the custom separator only appeared as last thousand separator. This is fixed by passing separator on the recursive call of prettify().

After these changes, all tests were passed.

What bug does this PR fix?

• There's a bug where iterations of three 9s (999, 999999, 999999999, etc) should round up to the next millname (999999 should become 1M, but displays 1000k).
• The cause was usage of the math.floor() when determining which prefix to append to inputted numbers. Floor rounds down to the nearest whole integer, forcing numbers that should be rounded up have one less millidx than they should at the time of string formatting. This has been replaced with python's native round() function, and has maintained the ability to use precision as an input parameter.
• drop_nulls logic has also been preserved in such a way that it happens during string formatting, thus the removal of remove_exponents() function which is unneeded with the current changes.
• prettify() logic remains untouched

How was this PR tested?

• Ran series of millify() calls on numbers with known bugged outputs, and verified they now round up as intended.
• Ran series of millify() calls on non-bugged numbers to verify they still work as intended, toggling the various outputs and testing those as well
• NOTE: using a precision= value of 3 or higher still produces 1000.000k instead of 1.000M. However, it's in my personal opinion that, when using this module, users shouldn't need/want more than two decimal places showing in their string output anyway. If these changes are accepted, this note should probably go in the README / patch notes. Further, if anyone can figure out how to preserve the correct millname while using a precision value of 3 or higher, I haven't been able to yet but am open to all ideas!

Related Ticket

• Closes #1
• NOTE: not sure how versioning works for this project, but I've left version = 0.1.1 as-is in this PR. Should these changes be accepted, you can determine if this needed versioned up to 0.1.2 or left alone! Thanks for reading, and kind regards!

Screenshots

• before (with bug):
• after (bug fixed):