Confusion around setting config values

[TomAugspurger]

In #603 (comment), @bdice raised an issue that I also ran into with the kvikio.defaults system. We have three methods per option, typically:

• kvikio.defaults.<option>
• kvikio.defaults.set_<option>
• kvikio.defaults.<option>_reset

It wasn't initially clear to me which of set_<option> and <option>_reset is method that immediately sets the value, and which is the one that must be used as a context manager. And I still mix it up occasionally.

I like the way donfig, which was based on the Dask config system, combines that into a single object that handles both immediately setting the value and is usable as a context manager.

>>> kvikio.defaults.set({option: value})  # set it permenantly

>>> with kvikio.defaults.set({option: value}): ...  # set it for the lifetime of the context manager

[bdice]

Yes, this API feels more Pythonic to me. I would support refactoring in this direction.

[madsbk]

Agree, looks like a good idea!

I would be good to include config of cuFile's DriverProperties, which is currently just exposed as a class: https://github.com/rapidsai/kvikio/blob/branch-25.04/python/kvikio/kvikio/cufile_driver.py#L11

[kingcrimsontianyu]

I think DriverProperties has already been made pretty Pythonic with the @property decorator. Is this what you have in mind as further improvement? @madsbk

# Only allow non-read-only properties to be set this way
with kvikio.cufile_driver.set({"poll_mode": True, "max_device_cache_size": 4096})

[madsbk]

Yes, I think it would be good to use the API style.