Something that has been flagged as a large quality of life improvement is the ability to customize type printout of missing values and floating-point numbers. Currently we’ve hard-coded these as
%.5e.format(d) respectively, and it would be great to parameterize them. The question is where. Should there be global type config set on init? Should it be set in each method that can stringify types? Should it be set on init and optionally overridden in each method that stringifies types?
This would be great! Also, if the representation of booleans could be set it would be awesome; right now when data needs to go from Hail to R it’s a bit painful
How about adding in
HailContext a dictionary of configuration settings—like formatting options and anything else that would be nice if they were “sticky”—and adding a method to
HailContext for modifying config settings? Perhaps methods could have optional parameters to override config settings that are relevant to the method, for those cases when you want a setting modification to apply to one method call only, then revert back to the global value. If there ended up being enough of these global settings, we might even allow for storing them in a config file that is read when creating a
HailContext, so users’ preferred settings can persist between sessions.
oh yeah, totally forgot bools on there @lfrancioli
@pschultz I think a global config file may be a good idea. It’s something I’d like to avoid if there are clean ways to get around it, especially because it’ll be a bit harder to configure with cloud, but may work best.
actually, we can just have it work with the hadoop file API and then it’s no different on the cloud.