Commit Graph

16 Commits

Author SHA1 Message Date
R David Murray 775632ba10 #19957: Simplify encode_7or8bit now that _payload is always str.
Patch by Vajrasky Kok, test enhancement by me.
2013-12-12 21:40:20 -05:00
R David Murray 00ae435dee #18324: set_payload now correctly handles binary input.
This also backs out the previous fixes for for #14360, #1717, and #16564.
Those bugs were actually caused by the fact that set_payload didn't decode to
str, thus rendering the model inconsistent.  This fix does mean the data
processed by the encoder functions goes through an extra encode/decode cycle,
but it means the model is always consistent.  Future API updates will provide
a better way to encode payloads, which will bypass this minor de-optimization.

Tests by Vajrasky Kok.
2013-08-21 21:10:31 -04:00
R David Murray f6069f9f22 #14360: make encoders.encode_quopri work.
There were no tests for the encoders module.  encode_base64 worked
because it is the default and so got tested implicitly elsewhere, and
we use encode_7or8bit internally, so that worked, too.  I previously
fixed encode_noop, so this fix means that everythign in the encoders
module now works, hopefully correctly.  Also added an explicit test
for encode_base64.
2013-06-27 18:37:00 -04:00
R David Murray ec317a8985 #17171: fix email.encoders.encode_7or8bit when applied to binary data. 2013-02-11 10:51:28 -05:00
R David Murray ceaa8b1d75 #16564: Fix regression in use of encoders.encode_noop with binary data. 2013-02-09 13:02:58 -05:00
R David Murray 78099bb153 Merge #9298 fix. 2011-03-16 16:13:07 -04:00
R David Murray 6d94bd470e #9298: restore proper folding of base64 encoded bodies.
Patch by Yves Dorfsman.
2011-03-16 15:52:22 -04:00
R David Murray 56a9d7e3da #11554: reactivate test_email_codecs, and make it pass.
The fix is to charset.py, which was not doing the encoding to the
correct output character set when doing a body_encode for either
the shift-jis or euc-jp charsets.  There's also a fix for handling
a bytes input in encoders.py.

Patch by Michael Henry, comment changes by me.
2011-03-15 12:20:02 -04:00
R. David Murray 99147c40b5 Merged revisions 81685 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/branches/py3k

........
  r81685 | r.david.murray | 2010-06-04 12:11:08 -0400 (Fri, 04 Jun 2010) | 4 lines

  #4768: store base64 encoded email body parts as text, not binary.

  Patch and tests by Forest Bond.
........
2010-06-04 16:15:34 +00:00
R. David Murray 7da8f06df0 #4768: store base64 encoded email body parts as text, not binary.
Patch and tests by Forest Bond.
2010-06-04 16:11:08 +00:00
R. David Murray f870d8736a Merged revisions 79996,80855 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/branches/py3k

................
  r79996 | r.david.murray | 2010-04-12 10:48:58 -0400 (Mon, 12 Apr 2010) | 15 lines

  Merged revisions 79994 via svnmerge from
  svn+ssh://pythondev@svn.python.org/python/trunk

  ........
    r79994 | r.david.murray | 2010-04-12 10:26:06 -0400 (Mon, 12 Apr 2010) | 9 lines

    Issue #7472: ISO-2022 charsets now consistently use 7bit CTE.

    Fixed a typo in the email.encoders module so that messages output using
    an ISO-2022 character set will use a content-transfer-encoding of
    7bit consistently.  Previously if the input data had any eight bit
    characters the output data would get marked as 8bit even though it
    was actually 7bit.
  ........
................
  r80855 | r.david.murray | 2010-05-05 21:41:14 -0400 (Wed, 05 May 2010) | 24 lines

  Merged revisions 80800 via svnmerge from
  svn+ssh://pythondev@svn.python.org/python/trunk

  It turns out that email5 (py3k), because it is using unicode for the
  payload, doesn't do the encoding to the output character set until later
  in the process.  Specifically, charset.body_encode no longer does the
  input-to-output charset conversion.  So the if test in the exception
  clause in encoders.encode_7or8bit really is needed in email5.

  So, this merge only merges the test, not the removal of the 'if'.

  ........
    r80800 | r.david.murray | 2010-05-05 13:31:03 -0400 (Wed, 05 May 2010) | 9 lines

    Issue #7472: remove unused code from email.encoders.encode_7or8bit.

    Yukihiro Nakadaira noticed a typo in encode_7or8bit that was trying
    to special case iso-2022 codecs.  It turns out that the code in
    question is never used, because whereas it was designed to trigger
    if the payload encoding was eight bit but its output encoding was
    7 bit, in practice the payload is always converted to the 7bit
    encoding before encode_7or8bit is called.  Patch by Shawat Anand.
  ........
................
2010-05-06 01:53:03 +00:00
R. David Murray ef3d6bd25f Merged revisions 79994 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk

........
  r79994 | r.david.murray | 2010-04-12 10:26:06 -0400 (Mon, 12 Apr 2010) | 9 lines

  Issue #7472: ISO-2022 charsets now consistently use 7bit CTE.

  Fixed a typo in the email.encoders module so that messages output using
  an ISO-2022 character set will use a content-transfer-encoding of
  7bit consistently.  Previously if the input data had any eight bit
  characters the output data would get marked as 8bit even though it
  was actually 7bit.
........
2010-04-12 14:48:58 +00:00
Barry Warsaw 8b2af27dae More email package fixes.
MIMEApplication() requires a bytes object for its _data, so fix the tests.

We no longer need utils._identity() or utils._bdecode().  The former isn't
used anywhere AFAICT (where's "make test's" lint? <wink>) and the latter is a
kludge that is eliminated by base64.b64encode().

Current status: 5F/5E
2007-08-31 03:04:26 +00:00
Guido van Rossum 8b3febef2f Copying the email package back, despite its failings. 2007-08-30 01:15:14 +00:00
Guido van Rossum 6398b7a351 Remove the email package for now.
Once Barry and the email-sig have a working new version
we'll add it back.
If it doesn't make the 3.0a deadline (release August 31), too bad.
2007-08-25 13:43:02 +00:00
Thomas Wouters 49fd7fa443 Merge p3yk branch with the trunk up to revision 45595. This breaks a fair
number of tests, all because of the codecs/_multibytecodecs issue described
here (it's not a Py3K issue, just something Py3K discovers):
http://mail.python.org/pipermail/python-dev/2006-April/064051.html

Hye-Shik Chang promised to look for a fix, so no need to fix it here. The
tests that are expected to break are:

test_codecencodings_cn
test_codecencodings_hk
test_codecencodings_jp
test_codecencodings_kr
test_codecencodings_tw
test_codecs
test_multibytecodec

This merge fixes an actual test failure (test_weakref) in this branch,
though, so I believe merging is the right thing to do anyway.
2006-04-21 10:40:58 +00:00