MemberOptions. It's great that we can add more, and it's great that OldStyleMemberships is smart enough to store them in a bitfield, but it seems silly to require that all MemberAdaptors do so...
...especially when other database systems that are used to drive Mailman will want to present interfaces for users to let them set these same options (and therefore will want to know the logical names of them, besides just their position in the bitfield). I guess what I'm suggesting is that instead of using this accessor like this: mlist.getMemberOption(addr, mm_cfg.OPTINFO['plain']), it be used like this: mlist.getMemberOption(addr, 'plain'), and inside OldStyleMemberships it does the mm_cfg.OPTINFO[] lookup. That way a Membership adaptor doesn't need to know that option "8" is DisableMime (but if it wants, it can find that the value option 'plain' is found by &'ing it's internal options bitarray with the value 8). I might alternately suggest that the values be bit locations, and the values to & be figured out with (1<<BitPosition), so that at least the "option numbers" be ordinal rather than powers of two. That is more much less important (more a stylistic thing), though. BTW, if I'm not mistaken, here's a typo in the comments in Defaults.py.in: "DEFAULT_LIST_OPTIONS" should be "DEFAULT_NEW_MEMBER_OPTIONS" What's the process for offering patches for things like this and the other interface changes I was suggesting Friday? Anyone have a chance to evaluate whether those made sense? Would changes like those be too dangerous this close to release? (Sorry it's taken me so long to actually get started helping out! :-) -Dale _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
