[mod_python] The new module loader

Dan Eloff wrote ..
> It sounds interesting, it might just finally solve all my importing woes.
> How do I enable this UMI?
> 
> Thanks,
> -Dan

See:

  http://issues.apache.org/jira/browse/MODPYTHON-143#action_12370976

Graham

> On 4/19/06, Graham Dumpleton <grahamd at dscpl.com.au> wrote:
> >
> > Dan Eloff wrote ..
> > > I am interested in how this unified module importer works and how it
> > avoids
> > > these problems.
> > >
> > > I'd really appreciate a brief description of it's architecture, not
> that
> > > you
> > > usually need all that much encouraging ;)
> > >
> > > Thanks,
> > > -Dan
> >
> > Bit busy today to elaborate too much, but you can start by reading my
> > far from complete document on it:
> >
> >   http://www.dscpl.com.au/articles/modpython-007.html
> >
> > Graham
> >
> > > On 4/19/06, Graham Dumpleton <grahamd at dscpl.com.au> wrote:
> > > >
> > > >
> > > > On 20/04/2006, at 8:06 AM, Dan Eloff wrote:
> > > >
> > > > > I went digging through the mod_python files and discovered how
> the
> > > new
> > > > > publisher loader works (using ModuleCache) and I borrowed the idea
> > > to
> > > > > import modules for my handler.
> > > >
> > > > Note that mod_python 3.3 will like be discarding that module loader
> > > > and the original one and replacing it with a grand unified module
> > > > reloader. :-)
> > > >
> > > > > The purpose of ModuleCache was to avoid sys.modules right?
> > > >
> > > > Yes.
> > > >
> > > > > I'm having some trouble with this, and I eventually tracked it
> down
> > > to
> > > > > multiple versions of a dependancy module being loaded.
> > > >
> > > > Known issue. See:
> > > >
> > > >
> > > > http://www.dscpl.com.au/articles/modpython-003.html#multiple-module-
> > > > instances
> > > >
> > > > > My handler loads one version, with empty module variables, while
> the
> > > > > actual modules for the pages load different version(s) and populate
> > > > > them with data. The changes are never reflected in the version
> kept
> > > by
> > > > > my handler (because they are not the same)
> > > > >
> > > > > This all makes sense, and is probably the intended effect, but
> what
> > > do
> > > > > you do for modules like Session in mod_python, where MemorySession
> > > > > uses a static class member to store sessions? Wouldn't the page
> > > > > modules each get their own version and thusly prevent sessions
> from
> > > > > working?
> > > >
> > > > Also see:
> > > >
> > > >
> > > >
> > http://www.dscpl.com.au/articles/modpython-003.html#transfer-of-module-
> > > > data
> > > >
> > > > > I need to be able to reload modified modules, but also to make
> use
> > > of
> > > > > shared modules. These seem to be conflicting needs, however. Does
> > > > > anybody have any inisght into this situation that they can share?
> > > >
> > > > Only that mod_python 3.3 will hopefully fix a lot of this stuff.
> If
> > you
> > > > are prepared to give 3.3 source code out of subversion repository
> a go
> > > > to see if things work as you expect, let me know and will tell you
> the
> > > > magic to enable the unified module importer in 3.3 as at moment it
> is
> > > > still off by default.
> > > >
> > > > Note though that even in 3.3, the "transfer of module data" issue
> > still
> > > > has to be explicitly dealt with in some way. Although not confirmed
> > how
> > > > this will be done, the new module importer as it stands now allows
> a
> > > > module to define a __clone__() method which will be called and which
> > > > can be used to transfer data from an old module to a new where data
> > > > needs
> > > > to be preserved across reloads.
> > > >
> > > > As I said, if interested I'll go into it more later.
> > > >
> > > > Graham
> > > >
> > > >
> >