On Thu, 31 Jan 2013 10:09:20 +0000, Daniel Reis <dreis...@hotmail.com> wrote:
> > PS: what is pyzlib? It sounds like a wrapper for zlib, which is what
> > I get when I google for it.
>
> I'm sorry, I mispelled it: I ment pyzmail
> (http://pypi.python.org/pypi/pyzmail). I do my best to stick to the
> standard library, so I didn't really use it (learned more about MIME
> instead). For some reason it came to my attention, but I cant't track
> back why. Top result on PyPi for "email" actually is the email-sig
> "alpha" module...
I will take a look at that at some point to see what he has found
useful API wise.
> > In 3.2, smtplib already has a send_message method that will accept a
> > Message object and send it. Once attaching things is easy, I think
> > that plus send_message will get you 90+% of the way to where you
> > would like to be.
>
> `send_message` makes an important step forward: it's able to read the
> "from" and "to" from the msg headers. Next step could be to assist in
> assembling the message. The `message` object 's constructor could
> accept parameters to accelerate new message creation in a single call:
> From, To, Cc, Bcc, Subject, and Body (HTML; TEXT). And then, as you
> said, make attaching things a little easier.
Well, I'd prefer to avoid that at this stage, and leave those
considerations for a later stage. This is because that would lock us in
to a particular, relatively complex API. It would probably be better to
leave that as a non-stdlib wrapper class for now, as we make the email
library more and more complete so that such wrappers become simpler and
simpler, until it becomes clear if/where to add it to the library.
> > I would welcome help working on this. If you want to assist, this list
> > is probably the best place to talk about it.
>
> Of course. Feel free to suggest me any directions. An idea is perhaps
> to discuss how using `message` objects should look like in some
> typical use cases, expanding what I said above in some code examples.
We have a somewhat-out-of-date wiki here:
http://wiki.python.org/moin/Email%20SIG
I should update that when I start working on this stuff next week, but
the design stuff provides some useful background for the work done so
far and the direction we think we are headed. (It's been a while since
I've reviewed it, so I/we may have made some specific decisions that
aren't reflected there.)
There is a list of use cases there, and expanding some of those with
thought experiments for how they would look in code might be useful.
Probably after discussing said thought experiments here :)
My first planned tasks are (1) review the wiki and update anything that
is out of date (2) go through the open issues list in the tracker and
fix the ones it is practical to fix at this stage and then (3) finish
making sure the new header code passes all of the tests that the old
header code passes by copying the tests in test_email.py into the
appropriate test_XXX files in Lib/test/test_email. This will, I
believe, result in a rewrite and simplification of the new header
folding code (which is currently ridiculously complex).
That list will take me through PyCon and beyond :).
So, right now the most helpful thing would be reviewing bugs (tagged
'email' in the tracker) and fixes. Alternatively you could take a look
at how I/we have done the header_factory in the new code, and think
about what the corresponding message_factory would look like. That will
be the thing that will make managing attachments easier, and is what I
plan to work on after finishing the list above.
In particular, we really haven't discussed and worked out how to make it
simple (yet consistent with the rest of the API) to specify, eg, a
multipart/alternative with a multipart/related subpart. I think that's
probably the biggest remaining design challenge for making this stuff
simple. My gut feeling right now is that the solution involves having
a class that acts as a multipart/related constructor, but I really
haven't thought much about it yet.
--David
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
