ENH: Support dict to pd.set_option for cleaner code

[yasirroni]

Feature Type

• Adding new functionality to pandas

• Changing existing functionality in pandas

• Removing existing functionality in pandas

Problem Description

I wish that I could use dict for pd.set_option, just like other packages typically accept dict when there are lots of option. Current pandas style follow what old programming language do, such as MATLAB.

Feature Description

import pandas as pd

options = {
    'display.precision': 2,
    'display.max_columns': 100,
    'styler.format.precision': 2,
}

# like this
pd.set_option(**options)

# or like this:
pd.set_option(options)

Alternative Solutions

Current implementations is:

pd.set_option('display.precision', 2)
pd.set_option('display.max_columns', 100)
pd.set_option('styler.format.precision', 2)

# or

options = {
    'display.precision': 2,
    'display.max_columns': 100,
    'styler.format.precision': 2,
}

for key, value in options.items():
    pd.set_option(key, value)

Additional Context

Because if I write it like this:

pd.set_option(
    'display.precision', 2,
    'display.max_columns', 100,
    'styler.format.precision', 2,
)

An auto formatter like ruff will make it into:

pd.set_option(
    'display.precision',
    2,
    'display.max_columns',
    100,
    'styler.format.precision',
    2,
)

[arthurlw]

take

[himanshumahajan138]

working on this

aah i missed it maybe

if i have solution can i propose it @arthurlw

[arthurlw]

Oh sorry @himanshumahajan138 I just saw your message. If you have a solution too we can discuss and compare!

[yasirroni]

Hi @arthurlw and @himanshumahajan138. Thanks for making the PR.

I think #61152 is cleaner, but has a higher risk of bug (if exist). Also, I don't think we need to support the ** approach as it is not based on args(?).

[himanshumahajan138]

@yasirroni actually i am struggling with the Tight code formatting fixtures 😅

Fixing the failing doc tests and type tests after that we can have discussions on approach suitability

[rhshadrach]

cc @pandas-dev/pandas-core for any thoughts.

[Dr-Irv]

I think it's a good idea to support a dict as an argument to set_option() although maybe we should introduce set_options() to support a dict so there is a difference between setting a single option versus multiple options in a single call?

[datapythonista]

I think it's a good addition, the same time makes things a bit complicated. @Dr-Irv makes the API clearer in my opinion, but I would prefer to not have to add and maintain one more method being almoat identical to the existing.

An idea could be since we are addimg a way to pass multiple options, to allow only one option and remove pd.set_option('s1': 1, 's2': 2) in favour of pasaing a dictionary instead. Not perfect, but feels like it'll male both the API and the code slightly aimpler.

In any case, I'm ok with any option.

[himanshumahajan138]

Good wishes Members,

Actually my PR consists both approaches first one is only for pd.set_option(options) and second is for both of the cases pd.set_option(options) & pd.set_option(**options)

PR : #61152

[arthurlw]

For my PR (#61151), I implemented the first approach only, which is pd.set_options(options), where options is a dictionary.

I think this would be simpler, but I am okay with either option.

[rhshadrach]

although maybe we should introduce set_options() to support a dict so there is a difference between setting a single option versus multiple options in a single call?

I think the issue with this is that pd.set_option can already set multiple options. So the API seems slightly confusing to me. In addition, I don't particularly like different functions that are very similarly named and do essentially the same thing with different argument types. To me, it'd be similar to proposing pandas have DataFrame.set_index and DataFrame.set_indexes.

[rhshadrach]

An idea could be since we are addimg a way to pass multiple options, to allow only one option and remove pd.set_option('s1': 1, 's2': 2) in favour of pasaing a dictionary instead. Not perfect, but feels like it'll male both the API and the code slightly aimpler.

Just to be sure, I think you mean to deprecate pd.set_option('s1', 1, 's2', 2). I'm in favor of this.

[arthurlw]

If we support dictionaries, I think it would make sense to deprecate pd.set_option('s1', 1, 's2', 2) as well. Added a deprecation warning to my PR for now.

[simonjayhawkins]

If we support dictionaries, I think it would make sense to deprecate pd.set_option('s1', 1, 's2', 2) as well. Added a deprecation warning to my PR for now.

This is not really a benefit for existing users that already the functionality of the current API to set multiple options at once?

[rhshadrach]

This is not really a benefit for existing users that already the functionality of the current API to set multiple options at once?

Reposting my response from the PR:

I find this to be a rough edge in pandas. Is there another package that allows the specification of options/configurations/settings as an iterable of alternating key-value pairs? It seems to me like an odd choice for an API, and one that we can improve by having users supply a data structure that more naturally embodies the key-value relationship.

[Dr-Irv]

I find this to be a rough edge in pandas. Is there another package that allows the specification of options/configurations/settings as an iterable of alternating key-value pairs? It seems to me like an odd choice for an API, and one that we can improve by having users supply a data structure that more naturally embodies the key-value relationship.

I agree! I'm all for having good design principles.

[mroeschke]

I would be +1 on supporting a mapping input.

I would be -0 on deprecating the current *args input. While agreed that it's not an intuitive way to pass setting-value pairs, not sure if it's worth the user churn to make users change the way they pass settings at this time. Maybe it would be worth deprecating in the future if we change the docs to just demonstrate and highly encourage passing a mapping.

[simonjayhawkins]

-1 is for the deprecation.

I think also that, without the deprecation, the enhancement could be conceptionally as simple as...

if len(args) == 1 and isinstance(args[0], dict):
     args = [elem for pair in args[0].items() for elem in pair]

which does not appear to be the maintenance burden to justify the deprecation.

The current PR has 2 extra branches and a lot of duplicated logic which is more of a maintenance burden IMHO.