You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on the next Unicode PR, which incorporates some global configurables,
and I can't seem to find a convention for handling that uniformly in pandas.
format.py has _GlobalPrintConfig/print_config, and core.api has the corresponding set_printoptions, It looks to me like they need to be integrated into something more general.
Examples from other projects:
matplotlib has rcParams
IPython does things differently with config.configurable , but still has a well defined way of
using/adding configurables.
I suggest a new core.config module to hold all configurables,
It will take over print_config (set_printoptions will keep working),
but will provide a more general namespacing scheme for configurables along with a
getter/setter to be added to core.api.
Once the getter/setter convention is put into place and used uniformly in the code,
the underlying implementation can change as necessary when pandas grows.
if this sounds reasonable, I can follow up with a PR. @wesm?
The text was updated successfully, but these errors were encountered:
I'm working on the next Unicode PR, which incorporates some global configurables,
and I can't seem to find a convention for handling that uniformly in pandas.
format.py has
_GlobalPrintConfig
/print_config
, and core.api has the correspondingset_printoptions
, It looks to me like they need to be integrated into something more general.Examples from other projects:
matplotlib
has rcParamsIPython
does things differently with config.configurable , but still has a well defined way ofusing/adding configurables.
I suggest a new
core.config
module to hold all configurables,It will take over print_config (set_printoptions will keep working),
but will provide a more general namespacing scheme for configurables along with a
getter/setter to be added to core.api.
Once the getter/setter convention is put into place and used uniformly in the code,
the underlying implementation can change as necessary when pandas grows.
if this sounds reasonable, I can follow up with a PR. @wesm?
The text was updated successfully, but these errors were encountered: