[Mailman-Developers] The one-giant-object approach

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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  
> mixes
> 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  
> improvements.

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  
simplifying principle.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRTgy0HEjvBPtnXfVAQJmxAQAsbBwBbwbpdaLYfvFIGSdJzqRJRVOYqbW
/iE51+WplcGHqjECGMitKSaoSTkRhH1bv6Wbmw++fe6ggEevFHUWpQ6eLqfx0Bup
YXGaWpuUBcuRRNGmkxXu2UHygt8/TJoxUtIPZfa/GeDr0Mmr/YOSDLNVwB8W5MCL
sObBU0xJhfw=
=6NVN
-----END PGP SIGNATURE-----