ENH: expose option_context as a top-level API GH5618
<del>
Moving `option_context` to toplevel rather then making `set_option` a context manager means
a one line change instead of metaclasses and config_prefix subtlety and the rest of the ich.
When a given approach to something explodes in complexity I'll [bravely, bravely run away](http://www.youtube.com/watch?v=BZwuTo7zKM8) every single time.
</del>


closes #5618
replaces #5625. 

@jtratner, your points about config_prefix being broken are valid, feel free to pick up in the future
if you're so inclined.

cc @jseabold

Why introduce a new name into the name space when you can just add `__enter__` and `__exit__` methods to `set_option`? I hit the meta class because I was doing too many things at once... 
 I didn't understand all the crud you had to work around until I tried it myself.
it makes the config_prefix stuff break and it makes the code feel like doing a summersault 
while reciting shakespeare backwards while doing taxes. It just makes me want to stand back.

The devs have been fine with this distinction for a long while, why's it not good enough for users?
 My bad, I misinterpreted the failing tests. Hopefully all green now with `set_option` as context manager.
Corrected authorship as well.
 Okay, sure. Just seems like you could do
`s/set_option/_prefixed_set_option/g` and then rename `option_context` to
`set_option` (and if you use it not as a contextmanager it's exactly the
same as `set_option`)
On Dec 19, 2013 6:05 PM, "y-p" notifications@github.com wrote:

> I didn't understand all the crud you had to work around Until I tried it
> myself.
> it makes the config_prefix stuff breaks and the summersault while reciting
> shakespeare
> backwards and doing taxes feel of the other out just makes me want to
> stand back.
> 
> The devs have been fine with this distinction for a long while, why's it
> not good enough for users?
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/pydata/pandas/pull/5752#issuecomment-30975432
> .
 Hmm, thought I did, I basically copy-pasted your code.
The docstrings for != set_option didn't work btw, the @property thing doesn't work
as expected for functions. I had to put in a fix. 

The option_context thing is just cleaner all around, but I think it's all there now.
 Go with whatever you like best. option_context is a much better name for it.
 Opted for exposing `option_context` as top-level API. It's just a simpler solution.
