-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
ENH: expose option_context as a top-level API GH5618 #5752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Why introduce a new name into the name space when you can just add |
I didn't understand all the crud you had to work around until I tried it myself. 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 |
Okay, sure. Just seems like you could do
|
Hmm, thought I did, I basically copy-pasted your code. 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 |
Make set_option into context manager
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.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