Skip to content

Consider changing naming convention for options variables #1153

Description

@genedan

Description

The chainladder options variables are currently in SCREAMING_SNAKE_CASE:

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.

Activity

  1. added this to the v1.0.0 milestone on Jul 25, 2026
  2. added theissue type on Jul 25, 2026
  3. updated Scope Both, Priority High and Effort Medium on Jul 25, 2026
  4. henrydingliu commented on Jul 29, 2026

    @henrydingliu
    Member

    making this the parent issue for all options-related issues

  5. self-assigned this
    on Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Fields

Priority

High

Effort

Medium

Scope

Both

Projects

Relationships

None yet

Development

No branches or pull requests

Issue actions