-----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@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-----

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

On Aug 1, 2006, at 12:31 AM, Mark Sapiro wrote:

Also, point bin/dumpdb at a config.pck to get a view of what's there.

Good point, thanks!

• -Barry

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

iQCVAwUBRM7a6nEjvBPtnXfVAQLrhAP/ePjyTFtR5ZlYtyzl8XdBS2Ftaee+lgy4 aRucKKcCObjcanwDW2OTZbXsLB+T8ClDpSeqkyT8rPNm0bMXm2AWbVrCdBqMO3xg UT7nZELBQmfdiax1mJnKp1HNfLZ1VhHTJmLA/ldjxnN6QfUyXPn1qCoOouRWFGkG BPtl1hHLmBw= =v5lb -----END PGP SIGNATURE-----