Is there a stupid Python trick to save me?
I had an interesting thing happen today; a list started to get two footers added to it. Odd.
Then I remembered why: I'd defined a pipeline for this list that had an extra module in it (my "BounceImplicit" module that just rejects Bccs; the custom list pipeline contained the old default + Bounce Implicit).
But now, Decorate shouldn't be in the pipeline, since it's called by SMTPDirect directly with the latest changes to SMTPDirect. So my pipeline calls it once explicitly and once implicitly. Oops.
It occurred to me that if there were some way to have a 'lazy evaluate' in a Python variable, I could maybe work around that, by saying "list.pipeline = mm_cfg.GLOBAL_PIPELINE + 'BounceImplicit' (or something like that) That way, if GLOBAL_PIPELINE changes, I still get the right effect.
But I don't know how I might mechanize something like that without hacking the code.
Am I smoking something, or is there some stupid Python trick that would allow "dynamic list composition from a value"?
(Alternatively, would it be worth having something that allows "add to the pipeline at a defined location" declarations, so that people can add custom modules but still track changes to the source? I realize that as an alpha tester I'm in a bit of a unique situation, but..)
"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
- Dan Mick (dmick@utopia.West.Sun.COM) [020314 09:23] wrote:
I had an interesting thing happen today; a list started to get two footers added to it. Odd.
Hi
We experienced the same case. In fact - initially we though there are two problems with strange similarity:
Problem with growing Re: Re: Re:[...]
Some users keep sending Subject: encoded ( in our case it was base64 ) Mailman doesn't look into encoded string, doesn't find Re: to remove, just adds its own Re: to the beginning of the Subject: header.
Sometimes Mailman haven't removed it's own signature
The same situation as previous, except whole mail content was encoded by the user, who had responded to the mail, and didn't removed list signature
We use 2.0.8
Regards
MJ.
-- Miroslaw.Jaworski@ipartners.pl ( Psyborg ) MJ102-RIPE Internet Partners Server Administration Department Manager
"Miroslaw" == Miroslaw Jaworski <mjaw@ipartners.pl> writes:
Miroslaw> We experienced the same case. In fact - initially we
Miroslaw> though there are two problems with strange similarity: -
Miroslaw> Problem with growing Re: Re: Re:[...]
Miroslaw> Some users keep sending Subject: encoded ( in our case
Miroslaw> it was base64 ) Mailman doesn't look into encoded
Miroslaw> string, doesn't find Re: to remove, just adds its own
Miroslaw> Re: to the beginning of the Subject: header.
This is fixed in CVS. Mailman is now base64/quoted-printable aware for the Subject: line, and will not add the "[Listname] " prefix if the "Listname" string is already in the subject.
Miroslaw> - Sometimes Mailman haven't removed it's own signature
Miroslaw> The same situation as previous, except whole mail
Miroslaw> content was encoded by the user, who had responded to
Miroslaw> the mail, and didn't removed list signature
In this case, Mailman will no longer add the signature to Base64 messages. If the user quotes the entire list signature and replies using Quoted-Printable, I'm not sure what will happen.
Ben
-- Brought to you by the letters W and U and the number 12. "A calpac is a large cap." Debian GNU/Linux maintainer of Gimp and Nethack -- http://www.debian.org/
- Ben Gertzfield (che@debian.org) [020314 10:04] wrote:
"Miroslaw" == Miroslaw Jaworski <mjaw@ipartners.pl> writes:
Miroslaw> We experienced the same case. In fact - initially we Miroslaw> though there are two problems with strange similarity: - Miroslaw> Problem with growing Re: Re: Re:[...] Miroslaw> Some users keep sending Subject: encoded ( in our case Miroslaw> it was base64 ) Mailman doesn't look into encoded Miroslaw> string, doesn't find Re: to remove, just adds its own Miroslaw> Re: to the beginning of the Subject: header.
This is fixed in CVS. Mailman is now base64/quoted-printable aware for the Subject: line, and will not add the "[Listname] " prefix if the "Listname" string is already in the subject.
Miroslaw> - Sometimes Mailman haven't removed it's own signature Miroslaw> The same situation as previous, except whole mail Miroslaw> content was encoded by the user, who had responded to Miroslaw> the mail, and didn't removed list signature
In this case, Mailman will no longer add the signature to Base64 messages. If the user quotes the entire list signature and replies using Quoted-Printable, I'm not sure what will happen.
I though so, although i didn't check it againts CVS :)
MJ.
-- Miroslaw.Jaworski@ipartners.pl ( Psyborg ) MJ102-RIPE Internet Partners Server Administration Department Manager
participants (4)
-
barry@zope.com
-
Ben Gertzfield
-
Dan Mick
-
Miroslaw Jaworski