[Mailman-Developers] Bounces, Pickles, Coding Styles Oh My

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 24, 2006, at 1:53 PM, emf wrote:

> After some non-trivial meditation on BounceRunner.py I think I know  
> the
> difference between verp_probe and verp_bounce, despite not quite  
> knowing
> what VERP means, the comment string for the two functions being
> identical, and the bodies of them being identical as well save a tiny
> little memory stanza.

VERP == Variable Envelop Return Path, although technically we're not  
actually doing VERP because that has to be done in the MTA.  We're  
doing the closest thing to VERP that an MLM can do.

The two functions are a bit different in other ways though, such as  
the regexp that they use and the fact that verp_probe() pulls data  
out of the pending database.

> Would someone be willing to change verp_probe's docstring to more
> clearly illustrate its function?

Sure, if I can remember :).  Seriously, verp_bounce() parses bounce  
messages.  Probes are similar but a bit different.  If we get a bunch  
of bounces from an address, we'll probe it for a while by sending it  
messages and seeing if the probes bounce as well.  We keep track of  
the probes in the pending database so that after the required number  
of probe bounces, we know the address is kaput.

> Also, I'm finding a fair number of files that aren't pep8/ 
> styleguide.txt
> happy. anyone care if I at least correct tab/space mixing, and/or make
> it otherwise style-guide correct?

Are there still files with tabs in them?  There definition shouldn't  
be.  Everything should be 4-space indents.

As for pep 8 style, I would eventually like to rename things, but as  
usual, that's more difficult than it sounds because for one thing,  
it's much harder to port fixes between the trunk and the branch after  
the rename.  We also don't want to do renames (or whitespace  
normalization for that matter) mixed in with significant changes  
because the latter will get buried in the diffs.  So I've taken the  
approach that all new code should be pep 8 compliant (with BAW  
additions :), but that existing stuff shouldn't be renamed... yet.

> As much as I appreciate the principles of code-hiding, it's been a bit
> of a pain to use the interpreter to figure out what is stored in a  
> pickle.

Heh.  And a database is better? :)

> Since I can't read the pickle file with my eyes, perhaps a little less
> obscuration might be OK?
>
> Like,
>
> list.members['i at mindlace.net'] doesn't work. In fact, I can't find any
> function that gives me a member in its entirety.

That's because there isn't any.  Much of the functionality embodied  
in the various member dicts have been added over time, so usually  
when we add something, like real names or bounce info, we've added a  
new dict keyed off the address, rather than worrying about backward  
compatibility with old dicts.

> It would help me if I could just see the underlying data; any
> suggestions on how?

Yep.  Just pop below the MemberAdaptor interface and access the dicts  
directly.   See OldStyleMemberships.py for which dicts contain which  
data (mostly organized this way for historical reasons).  You'll want  
to use bin/withlist listname to get the pickles loaded first, then  
explore the MailList attributes from there.

Hope that helps.
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iQCVAwUBRM7InHEjvBPtnXfVAQLdtAP/X7c59AVcqJXm033RDqK8v7QfJlfwIxv9
DRXkPCz5LCNtXP/v1UBj9QyUcmoYB9Ze+AkWLQNtWNgyBmtRNvrNBzQPCPKukUNB
0J5a0bNHS6XRK1/dzbVK/yjkwP7EWnBUprIDUNzCBfBn7RFL/4I8EhhsdAGgIIiM
4MlwY7Vmlh0=
=pCZh
-----END PGP SIGNATURE-----