Add a store of Rust classes to PyContext - #857

@coolreader18 thank's for your work on this. Getting a member from the module itself is not solved well at this point. I have mixed feelings about this change. On the one hand, it solves the issue of getting a rust type from the VM in a better way, rather then getting it via a get module hack. On the other hand, we still require the module if we want to retrieve a variable or function.

One other remark, with this route we store all rust classes of all modules on the pycontext, this potentially exposes all classes to all modules. I don't think this is the way to go.

I think is better to provide a mechanism such that each function in a module has access to its containing module. Maybe by extending the magic argument types with a OwnModule type like this:

#[pymethod(name="foo")
fn foo(vm: VirtualMachine, module: OwnModule, x: PyIntRef) {
  // use module here
  module.get_attr('')
}

Or maybe we can use a closure to fix this? Something like this:

fn make_module() {

SocketClass = py_class!();

#[pymethod(name="foo")
fn foo(vm: VirtualMachine, x: PyIntRef) -> SocketClass {
   SocketClass
}

}

In other words, I am not convinced this is the way to go.

What do you think about struct modules then? i.e. a module would be defined as a struct with specifically defined fields as well as a string-keyed dict, stored somewhere as just a dyn Any, and you would call maybe ctx.get_module::<OsModule>() to get it. That way, you could only access it if you can get a reference to a type that it corresponds to (which, btw, is how this rust_classes implementation works), so if you make that module struct private, it's completely encapsulated.

Yeah, I think that is already better. It sort of duplicates the sys.modules dictionary, but in a more fail safe way. Still I feel we could do something with scopes at the module sourcecode file level.

What you were describing with a fn declaration inside of the make_module function wouldn't work, because inline function declarations aren't closures; they can't capture any of the variables around them like ||{} closures can, and defining every function in a module as a closure would be sort of painful.

Okay, in that case I prefer to keep the current system with the strings. This also works, although it is a bit weird. Lets wait for the opinions of other reviewers.

I'm currently working on a struct modules implementation, which would eliminate the need for this. Should we close this for now?

Maybe leave this open to allow the others to have a look at this idea. What is the idea with the struct modules?

A RefCell<HashMap<TypeId, dyn Any>> stored on PyContext, and store_module<T>(&self, module: T) and get_module<T>(&self) -> T methods. I think T would be required to be Clone so we could get it out of the HashMap .

Or maybe get_module could accept a closure so someone could only clone what they need from the stored module.