I'm stressing this list again, but i stumbled over a missing
[message_]size().
http://wiki.python.org/moin/Email%20SIG/DesignThoughts makes it
a prerequisite for the new EMail package that
The API needs to at a minimum have hooks available for an
application to store data on disk rather than holding
everything in memory.
It would be great if the message (file) size would also be
provided as a public method, so that code-flow decisions can be
made dependend upon the plain size of a message.
(The size is known without parsing for many real-life message
objects anyway or can be detected *cheap*. True, e.g., for
all Message objects which are created by mailbox.py.)
It's also so unfortunate that 'headersonly' of Parser is in fact
treated as "a backwards compatibility hack", effectively consuming
the entire input nonetheless.
And *DesignThoughts* treats lazy parsing/partial loading as an
"interesting idea" only, though i can think about many cases where
it is a good thing to parse a Message{Headers[/Part/Part/Part...]}
sequentially.
E.g., why should a spam detector load an entire message if it only
wants to check addresses against some white-/blacklists and simply
throw away bad hits.
Even more, why should a companies dispatcher read all the content
if it's only about to rewrite addresses and dispatch the mail to
some other internal server.
(Of course - hey, it's you, you know *such* more about this stuff
than i do.)
Waiting is an electric experience ...
Have fun.
--
Steffen Daode Nurpmeso <sdao...@gmail.com>
:wq steffen
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
