I just got the latest Mailman sources from CVS, and noticed a couple of things.
- Required Python Version
Some of the modules (e.g., DNS.py) require Python 2.2 (e.g., reference to email modules). Yet the readme says Python 2.1.3 or greater is required. The wiki http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage says Python 2.0 will be required.
This is of particular concern for me because I'm thinking of borrowing some parts for a Zope product, and Zope 2.5 uses Python 2.1 and reportedly will not work with 2.2. This is, of course, not a good reason for Mailman to stay on Python 2.1.
I'm aware of the ZMailman project and sent a message to their list. However, what I'm doing probably goes in a different direction (I really just want the Bounce handling).
- Code Inconsistencies
Bouncer uses getBounceInfo. MemberAdaptor implements this (as well as OldMemberAdaptor), but MailingList doesn't inherit from it. So it looks as if everything is not quite hooked up yet.
- A Stylistic Comment
I also find it a little weird to see base classes making calls to methods that they don't define or inherit from, on the assumption that they will be mixed into something that does define them. It seems to me if this could be avoided, or at least if the classes could inherit from the classes with the relevant protocols, it would be cleaner. A lower tech approach would be to note the dependencies in class comments.
But I think the inheritance might make the dependencies explicit while still preserving the ability to factor out chunks of functionality.
- A Little Python Question
Could anyone explain to me what this is doing? (e.g. from DNS.py) return filter(None, addrs) There are several uses of this filter(None,..) idiom in the code.
The 2.0 code even says return filter(None, addrs) or None
The docs for filter say the first argument should be a function, which None is not. When I try it, it seems to be a noop (i.e., filter(None, foo) == foo). And or'ing with None (false) also seems pointless.