From dreis.pt at hotmail.com Wed Jan 30 17:08:26 2013 From: dreis.pt at hotmail.com (Daniel Reis) Date: Wed, 30 Jan 2013 16:08:26 +0000 Subject: [Email-SIG] FW: [Python-ideas] Standard library high level support for email messages In-Reply-To: References: , Message-ID: Hello all, I originally posted this to the python-ideas list, and am reposting it here following Barry Warsaw's advice: """ Python, as a "batteries included" language, strives to provide out of the box solution for most common programming tasks. Composing and sending email messages is a common task, supported by `email` and `smtplib` modules. However, a programmer not familiar with MIME won't be able to create non-trivial email messages. Actually, this proposal idea comes from the frustration of fast learning about MIME to get the job done, and later learn that some people?s email clients couldn't properly display the messages because I tripped in some details of multipart messages with Text+HTML and attachments. You can call me a bad programmer, but couldn't / shouldn't this be easier? Should a programmer be required to know about MIME in order to send a decently composed email with images or attachments? The hardest part is already built in. Why not go that one step further and add to the email standard library an wrapper to handle common email composition without exposing the MIME details. Something similar to http://code.activestate.com/recipes/576858-send-html-or-text-email-with-or-without-attachment, or perhaps including a lib such as pyzlib. """ Regards Daniel Reis -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Wed Jan 30 17:28:26 2013 From: rdmurray at bitdance.com (R. David Murray) Date: Wed, 30 Jan 2013 11:28:26 -0500 Subject: [Email-SIG] FW: [Python-ideas] Standard library high level support for email messages In-Reply-To: References: , Message-ID: <20130130162826.D2F95250BC7@webabinitio.net> On Wed, 30 Jan 2013 16:08:26 +0000, Daniel Reis wrote: > Python, as a "batteries included" language, strives to provide out of > the box solution for most common programming tasks. Composing and > sending email messages is a common task, supported by `email` and > `smtplib` modules. > > However, a programmer not familiar with MIME won't be able to create > non-trivial email messages. Actually, this proposal idea comes from > the frustration of fast learning about MIME to get the job done, and > later learn that some people??s email clients couldn't properly display > the messages because I tripped in some details of multipart messages > with Text+HTML and attachments. > > You can call me a bad programmer, but couldn't / shouldn't this be > easier? Should a programmer be required to know about MIME in order > to send a decently composed email with images or attachments? > > The hardest part is already built in. Why not go that one step further > and add to the email standard library an wrapper to handle common > email composition without exposing the MIME details. > > Something similar to > http://code.activestate.com/recipes/576858-send-html-or-text-email-with-or-without-attachment, > or perhaps including a lib such as pyzlib. I'm currently working on building up to this, starting at the bottom (the email package) and working my way up. I haven't been able to spend much time on it lately, but I plan to start again next month. At this point we have transparent handling of unicode in message headers when using the new email policies in 3.3. I still have some cleanup work to do there. Once that is done, the next step is making it easy to add attachments. We haven't fully worked out the design for that yet, though we had some extensive preliminary discussions a couple years ago :) 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. I would welcome help working on this. If you want to assist, this list is probably the best place to talk about it. --David PS: what is pyzlib? It sounds like a wrapper for zlib, which is what I get when I google for it. From dreis.pt at hotmail.com Thu Jan 31 11:09:20 2013 From: dreis.pt at hotmail.com (Daniel Reis) Date: Thu, 31 Jan 2013 10:09:20 +0000 Subject: [Email-SIG] FW: [Python-ideas] Standard library high level support for email messages In-Reply-To: <20130130162826.D2F95250BC7@webabinitio.net> References: , , <20130130162826.D2F95250BC7@webabinitio.net> Message-ID: > 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... > 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. > 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. Regards Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Thu Jan 31 13:48:04 2013 From: rdmurray at bitdance.com (R. David Murray) Date: Thu, 31 Jan 2013 07:48:04 -0500 Subject: [Email-SIG] FW: [Python-ideas] Standard library high level support for email messages In-Reply-To: References: , , <20130130162826.D2F95250BC7@webabinitio.net> Message-ID: <20130131124805.0F43F250BC1@webabinitio.net> On Thu, 31 Jan 2013 10:09:20 +0000, Daniel Reis 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