[PEAK] peak.running.logs in .ini files

[Phillip J. Eby]

At 01:56 PM 8/4/04 +0200, Radek Kanovsky wrote:

>Yes, I remember your post about this. There was a problem with
>TransactionService's logger that threw ImportError during logging
>so I have created this simple test application and it showed the
>same behaviour. TransactionService's logger is defined exactly as
>binding.Obtain(PropertyName('peak.logs.transaction')) :-)

Darn.  Thanks for pointing that out.


> > >It relates to 'logs' appearance in .ini files and probably to its 
> laziness.
> > >There are at least two solutions how to bypass this error:
> > >
> > >1. Reload lazy peak.running module before accessing lazy logs
> > >   from any .ini file (by uncommenting dir(running) in example)
> > >
> > >2. Redefine peak.logs.* property in .ini file, so definition doesn't rely
> > >   on lazy logs.
> > >
> > >   [peak.logs]
> > >   * = importString("peak.running.logs.LogStream")(
> > >                    stream=sys.stderr, levelName='WARNING'
> > >       )
> >
> > I'll take a look at this and see what I can find out.
>
>ImportError is raised by reload in util/imports.py:195. It denies to
>reload lazyModule('peak.running.logs') although this module seems OK.
>I was not able to find what's wrong yet.

Probably it's because something that the logs module wants to import is in 
the middle of being imported at the time the logs module is being 
loaded.  In other words, a circular import.  The weird thing in PEAK is 
that circular imports are usually okay, because of the lazy 
importing.  But, depending on the order of actual access, you can get 
circular imports that only cause a problem in one direction, and it's 
impossible to tell what's going on without close inspection.

I'm beginning to think they're a bad idea, especially since most of the 
modules that are lazily imported are ones in the core and will get loaded 
sooner or later if you use any other part of the core.  (e.g. binding, 
config, and naming).  There's probably little actual point in making those 
APIs lazy, and their laziness is probably the cause of the problem here.