[Mailman-Developers] The one-giant-object approach
barry at python.org
Fri Oct 20 04:22:08 CEST 2006
-----BEGIN PGP SIGNED MESSAGE-----
On Oct 19, 2006, at 3:45 PM, emf wrote:
> Take MailList. Aside from its own namespace, it mixes in 11 other
> classes, leading to 255 names if you dir(list).
> Is this large, flat namespace a preference? It seems to me like it
> together many bits of functionality that aren't always needed by
> whatever code needs a 'list'.
Personally I'm not very fond of the mix-in architecture of the
MailList classes. I believe it was originally intended to allow for
easy addition of functionality, but it just makes things more
complicated than necessary.
> It seems to me that if things were broken up a little bit they'd be
> conceptually easier to follow, and it'd be easier to make
I agree, but I think that will be difficult to impossible for 2.2.
OTOH, you can ignore many of the MailList attributes. If you emulate
what MailList.Save() does, you'll be fine. OTOH, ignore anything
that starts with an underscore or that is a MethodType.
> While I understand that a unified DB likely won't make it into 2.2, I
> would like to break out some functionality, and I just wanted to make
> sure that keeping a flat namespace wasn't a design goal.
BTW, I'd love to get a database approach for mailing list data,
rather than the current pickle approach. What we've always taken off
the table for 2.2 is the unified user database (i.e. one record per
user instead of one record per user per list). Even if all that data
was stored in a database, it would still be great if you could access
those values via attribute access syntax off the MailList instance.
Given the ability of Python to interpose attribute access, I think
that's possible. That does point to a flat namespace as a
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
-----END PGP SIGNATURE-----
More information about the Mailman-Developers