Consider changing naming convention for options variables

[genedan]

Description

The chainladder options variables are currently in SCREAMING_SNAKE_CASE:

chainladder-python/chainladder/__init__.py

Lines 181 to 184 in 07a92af

	self.ARRAY_BACKEND = "numpy"
	self.AUTO_SPARSE = True
	self.ARRAY_PRIORITY = ["dask", "sparse", "cupy", "numpy"]
	self.ULT_VAL = str(

I would recommend 2 changes:

1. Changing the naming convention to snake_case
2. Categorizing options with a prefix

Justification for the first item would be that options are mutable values and thus should not be capitalized like true constants. The other is that this style does not match that of the two major packages that we mirror, pandas and scikit-learn.

import pandas as pd
pd.describe_option()
compute.use_bottleneck : bool
    Use the bottleneck library to accelerate if it is installed,
    the default is True
    Valid values: False,True
    [default: True] [currently: True]
compute.use_numba : bool
    Use the numba engine option for select operations if it is installed,
    the default is False
    Valid values: False,True
    [default: False] [currently: False]
compute.use_numexpr : bool
    Use the numexpr library to accelerate computation if it is installed,
    the default is True
    Valid values: False,True
    [default: True] [currently: True]
...

import sklearn
config = sklearn.get_config()
config

{'assume_finite': False,
 'working_memory': 1024,
 'print_changed_only': True,
 'display': 'diagram',
 'pairwise_dist_chunk_size': 256,
 'enable_cython_pairwise_dist': True,
 'array_api_dispatch': False,
 'transform_output': 'default',
 'enable_metadata_routing': False,
 'skip_parameter_validation': False}

Clearly, this isn't some kind of universal rule. Polars does not follow this convention, so this issue is up for discussion:

import polars as pl
all_settings = pl.Config.state()
all_settings

{'POLARS_ENGINE_AFFINITY': None,
 'POLARS_FMT_MAX_COLS': None,
 'POLARS_FMT_MAX_ROWS': None,
 'POLARS_FMT_NUM_DECIMAL': None,
 'POLARS_FMT_NUM_GROUP_SEPARATOR': None,
 'POLARS_FMT_NUM_LEN': None,
 'POLARS_FMT_STR_LEN': None,
 'POLARS_FMT_TABLE_CELL_ALIGNMENT': None,
 'POLARS_FMT_TABLE_CELL_LIST_LEN': None,
 'POLARS_FMT_TABLE_CELL_NUMERIC_ALIGNMENT': None,
 'POLARS_FMT_TABLE_DATAFRAME_SHAPE_BELOW': None,
 'POLARS_FMT_TABLE_FORMATTING': None,
 'POLARS_FMT_TABLE_HIDE_COLUMN_DATA_TYPES': None,
 'POLARS_FMT_TABLE_HIDE_COLUMN_NAMES': None,
 'POLARS_FMT_TABLE_HIDE_COLUMN_SEPARATOR': None,
 'POLARS_FMT_TABLE_HIDE_DATAFRAME_SHAPE_INFORMATION': None,
 'POLARS_FMT_TABLE_INLINE_COLUMN_DATA_TYPE': None,
 'POLARS_FMT_TABLE_ROUNDED_CORNERS': None,
 'POLARS_MAX_EXPR_DEPTH': None,
 'POLARS_STREAMING_CHUNK_SIZE': None,
 'POLARS_TABLE_WIDTH': None,
 'POLARS_VERBOSE': None,
 'POLARS_WARN_UNSTABLE': None,
 'set_fmt_float': 'mixed',
 'set_float_precision': None,
 'set_thousands_separator': '',
 'set_decimal_separator': '.',
 'set_trim_decimal_zeros': False}

Justification for the second item is that the options variables is set to expand soon, and we should keep them categorized by type. (See #875 for proposed formatting enhancements) Therefore:

• ARRAY_BACKEND becomes backend.array
• AUTO_SPARSE becomes backend.auto_sparse
• ARRAY_PRIORITY becomes backend.array_priority
• ULT_VAL becomes date.ult_val
• display.value_format governs triangle value format
• display.value_precision governs triangle value precision
• display.pattern_format governs pattern format
• display.pattern_precision governs pattern precision

Is your feature request aligned with the scope of the package?

• Yes, absolutely!
• No, but it's still worth discussing.
• N/A (this request is not a codebase enhancement).

Describe the solution you'd like, or your current workaround.

No response

Do you have any additional supporting notes?

Would like to get this in as a 1.0 decision.

Would you be willing to contribute this ticket?

• Yes, absolutely!
• Yes, but I would like some help.
• No.

[henrydingliu]

making this the parent issue for all options-related issues