What to do with global curdoc #11554
Unanswered
bryevdv
asked this question in
Internals and design (Q&A)
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
cc @bokeh/dev
There are a few bits of global state remaining in Bokeh:
curdoc()
output_file
infoI would like to phase these out, or find ways to improve them. Especially global
curdoc()
. The latter is a bit annoying but is mostly useful in standalone scripts or the notebook and not quite as problematic. But to get rid of it, we could probably also just add an optionalfilename
arg toshow
and call it a day.On the other hand,
curdoc()
is a huge mess in Bokeh applications. We have to patch it in multiple place, it's probably not safe in some corner cases with threading, it's hard to reason about. It's not impossible to imagine keeping "curdoc" but making incremental improvements. E.g. we could make modules take care of their own "curdoc" so that calls tocurdoc()
inside them "do the right thing" without all the extensive patching:So if
curdoc()
is called inside a module that services a session, it grabs curdoc from the module it was called (not defined) inside of. But this is dynamic scoping, which is magic and generally frowned upon.At the other end of the spectrum, we can do something like the logging library does:
Then we can just arrange it so that the gotten "curdoc" is bound to and returns the appropriate doc for the session/module.
Im not sure. I don't like the idea of going down the road of more magic, tho reducing the patching is a slight win in my opinion. OTOH the second approach, while clearly cleaner, would break every Bokeh application so it would actually need a real, loud, long deprecation. Are there any other ideas?
Beta Was this translation helpful? Give feedback.
All reactions