[Email-SIG] API thoughts
Steffen Daode Nurpmeso
sdaoden at googlemail.com
Wed Mar 2 21:40:39 CET 2011
I've also read the updated EMAIL-SIG DesignThoughts.
But if "what goes in .defects[]" will be configurable i would hope
for a generic is_malformed() and maybe is_processable() or the
like, i.e. state versus (translatable?) user-info.
(The more i think about it the more i agree with David (i hope
i don't lie about that) that it's a waste of time to try to
convert malformed data to a compliant state, especially if the
package is - by design - capable to spit out the data the very
same way it came in. Someone will take care - and throw it away.)
I also go for lazy parsing when designing an email package.
(Pluggable) File-based backend.
Besides that all of this, and including the things David explained
in the issue tracker, sounds like smoked tofu to me. ;-)
Unfortunately my non-hate mail seems to have been mistreated as
spam 8-}, therefore i wrote all of the above just to thank David
once again for making the email and mailbox packages usable
already in Python 3.2. Thanks.
More information about the Email-SIG
mailing list