-----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['[EMAIL PROTECTED]'] 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----- _______________________________________________ Mailman-Developers mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
