options¶
options
sotres option and configuration data in a clean, high-function way.
Changes can “overlay” defaults or earlier settings.
For most code, options
is flexibility overkill. Not everyone wants to be a
world-class gymnast, yogi, or contortionist. For most functions and classes,
Python’s regular arguments, *args
, **kwargs
, and inheritance patterns
are elegant and sufficient. options
is for the top 1% that need:
- extremely functional classes, functions, and methods,
- with many different features and options,
- the settings for which might be adjusted or overriden at any time,
- yet that need “reasonable” or “intelligent” defaults, and
- that yearn for a simple, unobtrusive API.
In those cases, Python’s built-in, inheritance-based model stops being the
simple approach. Non-trivial argument-management code and complexity
begins to pervade. This is where options
’s layered, delegation-based
approach begins to shine. Almost regardless of how varied the options it
wrangles, or how much flexibility is required, code complexity remains flat.
Python has very flexible arguments for functions and methods, and
good connection of values from classes to subclasses to methods.
It doesn’t, however, connect those very well to configuration files,
module defaults, method parameters, and other uses. options
,
in contrast, seamlessly connects all of these varied layers and cases.
For more backstory, see this StackOverflow.com discussion of how to combat “configuration sprawl”.
For examples of options
in use, see say, quoter,
and show.