[TransWarp] usage of adviseModule('<module>') and other TW News

Phillip J. Eby pje at telecommunity.com
Mon Apr 29 21:34:13 EDT 2002

At 09:09 PM 4/29/02 +0200, Ulrich Eck wrote:
>i think my partner and myself a fairly fascinated of
>what can be done (with so little code) with TW .. it's indeed amazing :)

Thanks...  I'm hoping it works as well for Ty and I as we are about to 
start work on some things that will need the (development) speed boost -- 
we still haven't got the additional developers we really need.  :(

>how do i use adviseModule()

It's like module inheritance, but it patches the specified module, rather 
than inheriting from the module.  The idea is that you can have a 
standardized "hook point" module that other modules import, but which you 
want to have configurable at runtime based on which "advising" modules are 
imported first.

>I have one global Module, let's call it PackageConfig, that is imported
>from the Application. Every package will be installed in a seperate
>directory and is imported (via dir-list) at startup/reloadPackages.

One issue - I have done no real testing on reloading modules, especially in 
conjunction with adviseModule().  So let me know how it turns out.  :)

>i would like to avoid the need of a global config-module for packages.
>they are in the right directory .. so they will be loaded.
>could i use the following code to achieve this ??
>the importer is easy to write: for each dir in packagedir import 
>after all i should have a result like:
>         BasePackage
>         FirstPackage
>         SecondPackage
>Is this basically correct ??


>the following questions i have:
>- can this be done at runtime?

We're talking about Python here - there is no other time than run 
time.  :)  The only restriction is that a module which uses 
'adviseModule()' *must* be imported *BEFORE* the module it 
advises.  adviseModule() fails if a sys.modules entry already exists for 
the module being advised.

>- if yes: how does this affect instances of package-classes, that already 
>exist ??

It does not affect them, so don't create them until configuration is complete.

>- when are meta-classes executed (e.g. if DCClasses of Packages are 
>  that register their Type within the network .. actually doing this ..)

When using either advice or inheritance, a module's main code is always 
executed twice.  The first pass is "pure Python" semantics, and the second 
is with enhanced metaclass support.  For this reason, it is important that 
metaclass instantiation not have global side-effects.  It's also important 
for re-use.  Specifically, it is common to use a class as a composed 
element within more than one other class.  If you make assumptions about a 
class' global context, this makes it harder to reuse it.

>  a. when i advise a module, is it somehow interpreted again?  -> this 
> could end in multiple
>     registrations of a Type which is bad ..

Exactly.  Global registration should be in a module-level __init__() 
function, as described in the docs.  This will work with advice or 
inheritance.  If you need to chain between the multiple advising modules, 
use __proceed__() as usual.  You could have the config module __init__ 
create a registry and return it, and each of the advising modules could 
call __proceed__() to get the registry, then return it to their caller in turn.

>  b. best would be, if only new ActiveDescriptors are activated .. is this 
> possible ??

Not really.  The best advice is, don't create global side-effects from 
class creation!  Another way to address this issue with module-level 
__init__(), is to have __init__ look in the module globals for classes that 
implement an interface that indicates they need to be registered, and then 
register them.  Sort of like a module-level "ActiveDescriptors" metaclass 
init.  For that, you don't need to define additional __init__() methods in 
the advising modules.

>- what else should i take care of when trying this?

Heck if I know.  :)

>. so as we really consider to use TransWarp for our project:
>- Are any major changes scheduled for 0.2 (e.g. Database/SEF)

Not for 0.2.  0.3 may have significant Database upheavals, however.  We're 
likely to do some major work incorporating WarpCORE tools and a DDL 
generation system.  SEF changes don't seem terribly likely though.

>- Would you use TransWarp for a Project (mid-size UserManagement for 
>Win/Unix Networks)
>  that should reach first usable state end of summer ?? (without TransWarp 
> this would
>  probably not be doable ;-)

I'm going to have to, quite soon.  We have a major project in its early 
stages right now that will rely heavily on TransWarp for rapid 
development.  It's due in October.

>We have agreed, to open all sources of our basic services we implement in 
>We are basically interested in sharing work with others that have similar 
>actually planned are:
>                                                 ADSI/ADODB-Connection + 
> Model (read/write)
>                                                 ZODB-Connection + Model 
> (uses ZODB only for persistence
>but is quite handy for testing)
>                                                 improved LDAP/DataModel.
>                                                 if would be fine to see 
> them in TW.Database if they reach
>                                                 stable state .. possible ??

It's possible.  Most likely we will look and see what looks harvestable, 
and then incorporate ideas rather than code.  :)

>This is all work in progress ... nothing is ready yet, allthough the examples
>usually run. there are no unit-tests yet ... but we're making progress.
>anyone interested, have a look at:
>http://cvs.net-labs.de          (ViewCVS)
>again .. if you'ld like us to use module-names that do not contain 
>"TransWarp" please let
>us know soon ;-)

To avoid confusion, I'd prefer you didn't use the name.  If you want to 
call them things like "GUIforTW" or "DBforTW", that seems okay as long as 
the name is clearly something *for* TW rather than a part of it.  Thanks.

More information about the PEAK mailing list