>>>>> "DN" == Dale Newfield <[EMAIL PROTECTED]> writes:
DN> MemberOptions. It's great that we can add more, and it's
DN> great that OldStyleMemberships is smart enough to store them
DN> in a bitfield, but it seems silly to require that all
DN> MemberAdaptors do so...
DN> ...especially when other database systems that are used to
DN> drive Mailman will want to present interfaces for users to let
DN> them set these same options (and therefore will want to know
DN> the logical names of them, besides just their position in the
DN> bitfield).
DN> I guess what I'm suggesting is that instead of using this
DN> accessor like this: mlist.getMemberOption(addr,
DN> mm_cfg.OPTINFO['plain']), it be used like this:
DN> mlist.getMemberOption(addr, 'plain'), and inside
DN> OldStyleMemberships it does the mm_cfg.OPTINFO[] lookup. That
DN> way a Membership adaptor doesn't need to know that option "8"
DN> is DisableMime (but if it wants, it can find that the value
DN> option 'plain' is found by &'ing it's internal options
DN> bitarray with the value 8).
The problem that I have with this approach is that it's much easier to
let a typo like mm_cfg.OPTINFO['plian'] slip through than to use a
symbolic constant. E.g. tools like Pychecker can verify that the
constant exists, but can't really do much with the string.
DN> I might alternately suggest that the values be bit locations,
DN> and the values to & be figured out with (1<<BitPosition), so
DN> that at least the "option numbers" be ordinal rather than
DN> powers of two. That is more much less important (more a
DN> stylistic thing), though. BTW, if I'm not mistaken, here's a
DN> typo in the comments in Defaults.py.in: "DEFAULT_LIST_OPTIONS"
DN> should be "DEFAULT_NEW_MEMBER_OPTIONS"
That's not a bad alternative, and it preserves my desire for
constants, but I'm not sure it helps you much though. You still need
to know what values correspond to which options.
BTW, Thanks for the typo report.
DN> What's the process for offering patches for things like this
DN> and the other interface changes I was suggesting Friday?
DN> Anyone have a chance to evaluate whether those made sense?
DN> Would changes like those be too dangerous this close to
DN> release? (Sorry it's taken me so long to actually get started
DN> helping out! :-)
Something like this is probably going to be too late for MM2.1. The
best thing to do is to work out the patches and upload them to
SourceForge. At least there, they won't get lost in an inbox, and we
can re-examine them when MM2.1 final is released.
-Barry
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman-21/listinfo/mailman-developers
