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
signature.asc
Description: PGP signature
_______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
