On Thu, 03 Mar 2011 21:55:59 -0500, Barry Warsaw <ba...@python.org> wrote: > On Mar 02, 2011, at 08:23 PM, R. David Murray wrote: > >I'm not sure what we you mean by multiple registrations. Can you give > >an example? > > I really meant multiple registries, mostly thinking about how to avoid some > global state. But Python already has some global registries, so maybe that's > not too bad in this case.
Ah, yes. Well, so far my thought is that there is a global registry for the email package itself, but since email package access to that registry will be through the 'factory', there is nothing that says that has to be the only registry used by an application. The existence of the email package global registry will allow the addition of classes to the "default" registry by libraries (if we dare :) and applications, while access through the factory means that an application is free to manage a completely independent registry if it prefers. Or perhaps it is better to think about the default email package registry as just that, the *default* registry, since I think it's only specialness will be that it is the registry that is used by default. But that's just my current thought, if anyone can think of a better design I'm all ears. I should note that one design concern I have in all this is that it so far looks like importing email will, under this registry design, end up importing pretty much *all* of the email classes (and there will be more of them than in the current package). I'm so far ignoring that issue, treating it as a premature optimization, but if anyone has any clever ideas or other thoughts, let me know. --David _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
