so are we agreed on this then? -
- new iScriptModule object, supporting overloaded Call
- internal hash of iScriptModule objects in iScript, which can be looked up using FindLoadedModule(const char*)
- Do we break the current LoadModule for python? (as far as I'm aware
the RunText should still work, because loading the modules should
include them in global interpreter - TODO: check this out). If it does
break behaviour, should I precede or make a new LoadModuleObject or
something
- AddModuleLoadingPath function to update PYTHONPATH variable (takes a
const char of a VFS path which is internally translated to absolute
path)
Alternatively we could do away with the iScriptModule object, and store
the raw python module objects (merely adding an extra modulename
argument to iScript::Call)
Just thought I'd make some pointers in case we followed the 'alternative' method...
- no new iScriptModule object
- Same Call functions, but function names must have unique identifiers since they all exist in global scope
- LoadModule stays, but also get LoadScriptFile function
- no need for AddModuleLoadingPath since LoadScriptFile takes a path to python script
Amir Taaki
- Re: [CsMain] new csPython Amir Taaki
- Re: [CsMain] new csPython Chris Case
- Re: [CsMain] new csPython Mathew Sutcliffe
- Re: [CsMain] new csPython Mathew Sutcliffe
- [CsMain] new csPython Amir Taaki
- Re: [CsMain] new csPython Michael D. Adams
- Re: [CsMain] new csPython Neutral Robot Boy
- Re: [CsMain] new csPython Jorrit Tyberghein
- Re: [CsMain] new csPython Neutral Robot Boy
- Re: [CsMain] new csPython Mathew Sutcliffe
- Re: [CsMain] new csPython Neutral Robot Boy
- [CsMain] new csPython Amir Taaki
