Skip to content

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

Merged
3 commits merged into from Dec 31, 2013
Merged

ENH: expose option_context as a top-level API GH5618 #5752

3 commits merged into from Dec 31, 2013

Conversation

ghost
Copy link

@ghost ghost commented Dec 19, 2013

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

@jtratner
Copy link
Contributor

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...

@ghost
Copy link
Author

ghost commented Dec 19, 2013

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?

@ghost
Copy link
Author

ghost commented Dec 20, 2013

My bad, I misinterpreted the failing tests. Hopefully all green now with set_option as context manager.
Corrected authorship as well.

@jtratner
Copy link
Contributor

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" [email protected] 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//pull/5752#issuecomment-30975432
.

@ghost
Copy link
Author

ghost commented Dec 20, 2013

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.

@jtratner
Copy link
Contributor

Go with whatever you like best. option_context is a much better name for it.

@ghost
Copy link
Author

ghost commented Dec 31, 2013

Opted for exposing option_context as top-level API. It's just a simpler solution.

ghost pushed a commit that referenced this pull request Dec 31, 2013
Make set_option into context manager
@ghost ghost merged commit 1ebb31e into pandas-dev:master Dec 31, 2013
@ghost ghost deleted the PR_expose_option_context branch December 31, 2013 00:49
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

set_option as a context manager
1 participant