homepage

Python: 2.4
Module: email.Header
Method: encode()
In some cases returns unicode (example on line 5)
1>> from email.Header import Header
2>> Header(unicode('abcá','iso-8859-2'),'utf-8').encode()
'=?utf-8?b?YWJjw6E=?='
3>> Header('abc','utf-8').encode()
'=?utf-8?q?abc?='
4>> Header(u'abc','utf-8').encode()
'abc' ???
5>> Header('abc','iso-8859-2').encode()
u'=?iso-8859-2?q?abc?=' (P2.4)
6>> Header('abc','iso-8859-2').encode()
'=?iso-8859-2?q?abc?=' (P2.3)

I made some new tests in P2.6.1
>>> import email.charset
>>> c=email.charset.Charset('utf-8')
>>> print c.input_charset, type(c.input_charset)
utf-8 <type 'unicode'>
>>> print c.output_charset, type(c.output_charset)
utf-8 <type 'str'>
but
>>> c=email.charset.Charset('iso-8859-2')
>>> print c.input_charset, type(c.input_charset)
iso-8859-2 <type 'unicode'>
>>> print c.output_charset, type(c.output_charset)
iso-8859-2 <type 'unicode'>
but if you use alias latin-2 it's OK
>>> c=email.charset.Charset('latin-2')
>>> print c.input_charset, type(c.input_charset)
iso-8859-2 <type 'str'>
>>> print c.output_charset, type(c.output_charset)
iso-8859-2 <type 'str'>
>>> 
Error is here for unicode input-charset:
self.input_charset->conv->self.output_charset
module email/charset.py line 219
 if not conv:
 conv = self.input_charset
for the charsets where aren't output conversions
CHARSETS = {
 # input header enc body enc output conv
 'iso-8859-1': (QP, QP, None),
 'iso-8859-2': (QP, QP, None),
and if you don't use alias
ALIASES = {
 'latin_1': 'iso-8859-1',
 'latin-1': 'iso-8859-1',
 'latin_2': 'iso-8859-2',
 'latin-2': 'iso-8859-2',
But the realy source of this error is on line 208
 input_charset = unicode(input_charset, 'ascii')
because this construction returns unicode
>>> print type(unicode('iso-8859-2','ascii'))
<type 'unicode'>

Any hope of this being fixed?

I believe that RDM is working on this sort of issue as part of email6.

I've attached a fix and test. I've uploaded them separately since the fix only applies to 2.7, but I want to put the test into 3.x as well.

Committed to 2.7 in r87515. On second thought there's no reason to forward port the test because Python3 doesn't have the equivalent type-promotion issues.