email: Attempt .as_string() if BytesGenerator.flatten() fails
authorW. Trevor King <wking@tremily.us>
Sat, 16 Feb 2013 14:06:38 +0000 (09:06 -0500)
committerW. Trevor King <wking@tremily.us>
Sat, 16 Feb 2013 14:06:38 +0000 (09:06 -0500)
commit1c97270ee6d5d0cdb79cd025c17689fd342890bd
tree13ae8b98f4b16f1464a66ad1c71fdf7088ab95f9
parent9ce68de485847c80c4d8a4b09ee7bc3b3ab9b210
email: Attempt .as_string() if BytesGenerator.flatten() fails

Before converting BytesGenerator in 8a907f9 (email: Fix _flatten()
implementation for non-ASCII bodies, 2013-01-23), we used to flatten
emails with message.as_string().  BytesGenerator should be the more
robust approach, but it is, unfortunately, broken with respect to
Unicode payloads [1,2,3,4].  This makes the use-8bit setting pretty
useless.

Until we find a clean fix for BytesGenerator, fall back on the earlier
.as_string() approach where possible.  We check the feasibility of the
fallback by performing a quasi-round-trip and comparing a message
recovered from the byte-encoded form with the original message.  If
the recovered version does not match the original message, we reraise
the BytesGenerator.flatten() error.  This fallback should work for
any charset who's mapping for ASCII characters is a no-op.

One benefit of this altered approach is that we no longer need to
encode the payload when we set it up in get_message().  This "Unicode
inside--encode on output" approach doesn't smell as much as the old
approach ;).

The new fallback will probably die screaming if you try and flatten a
multipart message, but we don't do that in rss2email.  Hopefully, the
upstream issues with the email library will be sorted out in the near
future...

[1]: http://thread.gmane.org/gmane.comp.python.general/725425
[2]: http://bugs.python.org/issue16324
[3]: http://bugs.python.org/issue12553
[4]: http://bugs.python.org/issue12552#msg140294

Signed-off-by: W. Trevor King <wking@tremily.us>
rss2email/email.py