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.