[Mailman-Developers] Is there a stupid Python trick to save me?

[Barry A. Warsaw]

>>>>> "DM" == Dan Mick <dmick@utopia.West.Sun.COM> writes:

    DM> I had an interesting thing happen today; a list started to get
    DM> two footers added to it.  Odd.

There was a bug, now fixed in CVS which caused decorations to be added
to stuff like messages to list-owner.  I've added a block in
Decorate.process(): if the metadata has a true 'nodecorate' key, it
short-circuits the decoartions.

Not directly related, but just FYI.

    DM> It occurred to me that if there were some way to have a 'lazy
    DM> evaluate' in a Python variable, I could maybe work around
    DM> that, by saying "list.pipeline = mm_cfg.GLOBAL_PIPELINE +
    DM> 'BounceImplicit' (or something like that) That way, if
    DM> GLOBAL_PIPELINE changes, I still get the right effect.

    DM> But I don't know how I might mechanize something like that
    DM> without hacking the code.

    DM> Am I smoking something, or is there some stupid Python trick
    DM> that would allow "dynamic list composition from a value"?

There are a couple of things that might be possible, but I'm pulling
both ideas out of my ass at the moment.  Haven't tried either.  In
Python 2.2 you could possibly use descriptors on new-style classes to
define this kind of lazy evaluation.  Actually descriptors are a very
cool idea that will probably be used extensively in MM3.0 to provide
customizability in the database and web gui interchanging dimensions
w/o sacrificing readability.

If you wanted to take a large bite (or risk brain explosion), you
might look into acquisition, which is a technique used in Zope for
finding attributes based on containment heirarchy, as opposed to the
traditional inheritence heirarchy.  Very neat idea, except that
implicit acquisition can be exceedingly frustrating when it goes wrong
(explict acquisition might not be as bad).

    DM> (Alternatively, would it be worth having something that allows
    DM> "add to the pipeline at a defined location" declarations, so
    DM> that people can add custom modules but still track changes to
    DM> the source?  I realize that as an alpha tester I'm in a bit of
    DM> a unique situation, but..)

For the IncomingRunner, it should be easy.  Create a subclass of
IncomingRunner, and override the _get_pipeline() method.  Then
override the QRUNNERS variable in your mm_cfg.py to use your new
subclass rather than IncomingRunner.  Again, untested, but a bit
easier to do, and much safer on the brain the above two half-baked
ideas.

-Barry