I imagine a lot of people are finding out what options are available by looking at the docstring of set_printoptions, whereas set_option doesn't have any docs. What do you suggest?

You're right, I did/do too.
I thought describe_option() would answer that need, but I guess that's an extra step.
Adding all the options to the set_option docstring won't scale far, but I guess at least
for now it won't make things more difficult.

Could also create a pd.options hirerachy mirroring the registered options, with
a __dir__ hack. And have __getitem__ and __setitem__ wrapping get/set_item.

or both.

what do you think is best?

The doctsrings for all the options API functions now include a list of options and their
descriptions. The option lists are generated on the fly from the data structures of the
config module.
The listing is wrapped so it looks nicer then what set_printoption currently does
for me in qtconsole.

In [3]: ?pd.set_option
Type:       CallableDyanmicDoc
String Form:<pandas.core.config.CallableDyanmicDoc object at 0x3439b90>
File:       /home/user1/src/pandas/pandas/core/config.py
Definition: pd.set_option(self, *args, **kwds)
Docstring:
set_option(pat,value) - Sets the value of the specified option

Available options:
print_config.[colheader_justify, column_space, date_dayfirst, date_yearfirst,
              digits, encoding, float_format, max_columns, max_colwidth,
              max_rows, multi_sparse, notebook_repr_html, pprint_nest_depth,
              precision]

Parameters
----------
pat - str/regexp which should match a single option.

Returns
-------
None

Raises
------
KeyError if no such option exists

print_config.colheader_justify: No description available.

print_config.column_space: No description available.

print_config.date_dayfirst: 
: boolean
        When True, prints and parses dates with the day first, eg 20/01/2005
print_config.date_yearfirst: 
: boolean
        When True, prints and parses dates with the year first, eg 2005/01/20
print_config.digits: No description available.

print_config.encoding: 
: str/unicode
        Defaults to the detected encoding of the console.
        Specifies the encoding to be used for strings returned by to_string,
        these are generally strings meant to be displayed on the console.
print_config.float_format: No description available.

print_config.max_columns: 
: int
        max_rows and max_columns are used in __repr__() methods to decide if
        to_string() or info() is used to render an object to a string.
        Either one, or both can be set to 0 (experimental). Pandas will figure
        out how big the terminal is and will not display more rows or/and
        columns that can fit on it.
print_config.max_colwidth: No description available.

print_config.max_rows: 
: int
print_config.multi_sparse: 
: boolean
        Default True, "sparsify" MultiIndex display (don't display repeated
        elements in outer levels within groups)
print_config.notebook_repr_html: 
: boolean
        When True (default), IPython notebook will use html representation for
        pandas objects (if it is available).
print_config.pprint_nest_depth: 
: int
<...>

changed to print.X, every little bit counts.

Merged this, thanks. One downside I can think of immediately is the lack of tab completion. With set_printoptions, you can tab-complete all of the options in IPython, like the untidy notebook_repr_html. I'll think about whether I really want to deprecate the method =/

Agreed. Obiously it would be cleaner to have a single interface though.
Note that the functions accept a re.search-style regexp, so set_option("k_repr",False) should work.

Is there a discussion somewhere of the benefits of the lack of kwargs in set_option over the way set_printoptions works? The only difference I've experienced is no tab-completion but just a really long doc-string to scroll through.

Tab-completion was addressed with pd.options.
You can use describe_option, which accepts a regexp to get help on a specific option.
having the options held in a datstructure, rather then hard-wired into a signature
had some benefits, one of which is that it eliminated docstring rot, the description
is attached to an option once in config_init and is then dynamically inserted in several places,
including the docstrings for the various options API functions.

overall, I think we got it right.

Ok thanks. And just to be sure, the recommended tab-complete way of doing

pd.set_printoptions(max_columns=30, notebook_repr_html=False, max_rows=200, colheader_justify='left')

is now

pd.options.display.max_columns = 30
pd.options.display.notebook_repr_html = False
pd.options.display.max_rows = 200
pd.options.display.colheader_justify = 'left'

right?

afict, wes decided to keep set_printoptions around since those are the most
often tweaked options - but yes.

Well there is a deprecation warning there. I was thinking it'd be better to remove set_printoptions later this year.