[Email-SIG] API thoughts

R. David Murray rdmurray at bitdance.com
Fri Mar 4 14:33:04 CET 2011


On Thu, 03 Mar 2011 21:55:59 -0500, Barry Warsaw <barry at 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


More information about the Email-SIG mailing list