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