float_format kwargs doesn't work as intended about prettytable HOT 6 CLOSED

I'll put it on my list and hopefully get to it in the next decade :)

I wanted to at least post this for Googlers.

from prettytable.

Thanks for the report, would you like to have a look into putting a fix PR together? :)

from prettytable.

Would you mind elaborating on what kind of fix you'd like to see for this? This appears to be a pattern shared by a few of the setters and not specific to float_format:

Where in the else clause there's nothing to iterate over during instantiation without anything passed to field_names, as in the OP's example, and the float_format argument is discarded. If there are fields present, then they're set as expected but, perhaps unintuitively, any new fields are not.

e.g.

from prettytable import PrettyTable

table = PrettyTable(("foo",), float_format=".2")
table.add_row([1.0])
print(f"Instantiation:  {table.float_format=}")

table.add_column("bar", [2.0])
print(f"Column added:   {table.float_format=}")

table.float_format = ".2"
print(f"Set formatting: {table.float_format=}")

Instantiation:  table.float_format={'foo': '.2'}
Column added:   table.float_format={'foo': '.2'}
Set formatting: table.float_format={'foo': '.2', 'bar': '.2'}

Things I can think of:

• Issue a warning from these setters when they don't apply anything
• Extend arguments to methods like add_column to allow format specification (and other relevant properties)
• Cache these inputs as "defaults" (perhaps with a different kwarg name?) and, if they're present/relevant, apply them to any new field(s) as they're added.

from prettytable.

Not that I'm a contributor or anything, but in my experience, a warning is always better than failing silently, and a logic error tends to be more pervasive than a syntax error.

If the use cases where developers would encounter the warning incorrectly are rare and primarily encountered by developers attempting to do very complicated things, then that seems like a solid middle ground that can't break anything.

from prettytable.

It's pretty frustrating, because this code results in different behavior:

table.field_names = ['foo', 'x']
table.float_format = '.2'   # x printed with 2 digits of precision

vs

table.float_format = '.2'       # float_format is {}
table.field_names = ['foo', 'x']   # x will be printed with 6 digits of precision

The documentation says nothing about this having to be set after columns are defined. It looks like the code allows for different columns to have different formats, since it is stored as a dict, but it isn't clear at all how you would do that via the api.

More specifically, the documentation states that float_format is a string. But it isn't, it is a dict. It is just the setter accepts a string. If you print table.float_format you see that, and then things like this work:

table.float_format = '.2'
table.float_format['x'] = '.6'

This is somewhat easy to live with if it was documented in the readme. It is not clear if this is supported behavior - the next check in could break this. But why else is it a dict?

I would prefer it optionally not be a dict; if not it globally applies to all fields. Because why? I have a bunch of reports to make, and I want the same settings for all, and I want a function to create a table for me so I don't have to put the same boilerplate everywhere. So, I wrote this, it didn't work, and I came here and discovered this issue.

def _make_pretty_table(prec: int = 2):
    pt = PrettyTable()
    pt.float_format = f'.{prec}'
    pt.border = False
    return pt

According to the documentation this should work, but of course it doesn't. I'd agree with trhr' comment that a warning would be nice.

But I would argue this sort of stateful behavior is not a good design, because it forces the user of the class to understand the programming underneath. A reader (such as a code reviewer) would have essentially no chance of catching the bug in my second code example. The combination of allowing _float_format to be a string (and hence applied to all columns), or a dict, and adding a column property setter to set the format of a specific column without reaching in and manipulating the dict directly is best.

from prettytable.

Please can you have a look at PR #136 and see if it would address your needs?

from prettytable.