Currently, functions like vals.fmt_number() work as follows:
The input list or value is converted to a pandas DataFrame
The DataFrame is wrapped in GT
The corresponding fmt_ method is run
The formatted values are extracted as a list
This is problematic for two reasons:
It creates a hard dependency on pandas
It feels a bit circuitous to wrap in GT, run, then take out
Removing use of GT
Fortunately, it seems that GT.fmt_* methods don't make much use of the GT object. Uses seem to be largely:
Getting a default locale setting
Passing in the DataFrame to dispatch on for is_na() checks
At the very end, attaching to GT._formatters, and returning a new GT object
It seems like we could pretty easily run vals.fmt_* funcs straight over formatter logic. This would let us remove the pandas dependency.
Alternatively..
An alternative would be for us to support GT(SomeInBuiltFrame). GT's core logic does not require a very beefed up DataFrame implementation. We could get away with a class that's essentially a dictionary of same-length lists. This might actually be easier, since we wouldn't need to refactor the formatter code.
We could support inputting a pandas series or polars series as the input values. We have the machinery to detect these, and at that point do pandas/polars specific things w/o creating any dependencies.
Currently, functions like
vals.fmt_number()
work as follows:This is problematic for two reasons:
Removing use of GT
Fortunately, it seems that
GT.fmt_*
methods don't make much use of theGT
object. Uses seem to be largely:is_na()
checksIt seems like we could pretty easily run
vals.fmt_*
funcs straight over formatter logic. This would let us remove the pandas dependency.Alternatively..
An alternative would be for us to support
GT(SomeInBuiltFrame)
. GT's core logic does not require a very beefed up DataFrame implementation. We could get away with a class that's essentially a dictionary of same-length lists. This might actually be easier, since we wouldn't need to refactor the formatter code.