I've used OpenGL for years now, and have become reasonably skilled with it. However, I'm trying some new things with the overall architecture of my games, and I'm finding that I don't fully understand OpenGl context scope.

Will the following work:
1) In my game's main (and probably only) thread, I create a window with an OpenGL context that is set to the "current OpenGL context"
2) Then, I call functions from a dynamically loaded library -- this library makes OpenGL calls (however, it does not create a window/context for itself, it just assumes there is one)
Do things work that way?

And how about the more complicated version:
1) In my game's main (and probably only) thread, I create a window with an OpenGL context that is set to the "current OpenGL context"
2) Then, from this main thread I execute a Python script with an embedded Python interpreter.
3) This Python script imports and uses a Python module (actually just a Python binding for the "dynamically loaded library" mentioned above), and this module makes OpenGL calls internally (again, without creating an OpenGL context -- instead just assuming there is one -- which is what I want [to use the context I created earlier -- created outside the interpreter])
Do things work that way too?

And if things do not work these ways, is there a way I can make such an architecture that works?
Thanks!

OpenGL doesn't care where calls are coming from, or how you structure your code. It only cares about one thing: a rendering context can be bound to a single thread only at any time, and as long as calls are made from that thread, it doesn't matter how the calls are made.

So the only thing that matters in your descriptions are the "(and probably only)" parts. If there's only one thread, then you're safe. If there are more threads where calls can/will be made, you have to be very careful to ensure the context is moved between threads before making calls to OpenGL.

Personally I would avoid making OpenGL calls on more than one thread; if you need to go multi-threaded then make all your rendering calls nothing more than commands which go into a rendering queue. Then the thread which owns the OpenGL context can pick these calls off the queue and execute them.

This also allows you to do things like batch up all the calls in a scene, sort them for state and then send them in one batch to be rendered why you get on with the logic for the next chunk of the scene.