[Email-SIG] API thoughts

[Barry Warsaw]

On Mar 04, 2011, at 08:33 AM, R. David Murray wrote:

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

I think that's a great place to start.

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

Yeah, that's a problem.  Maybe we (the Python community) should invest in good
lazy importing support for Python 3.3?  I know that this has been reinvented
several times already.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/email-sig/attachments/20110304/efa623de/attachment.pgp>