Lib/encodings/idna.py claims to do the following when `input` is a
string object (lines 183-184, and see comment line 178: "IDNA allows
decoding to operate on Unicode strings, too"):

            # Force to bytes
            input = bytes(input)

This is obviously wrong, lacking an encoding parameter. It doesn't seem
to be covered in the test suite, and I don't know what the proper
semantics should be, so I leave it to someone else to find a fix.

Martin, you seem to be the author of that module.

Martin's original code (r32301) was pretty clear:

 32301     loewis         # IDNA allows decoding to operate on Unicode strings, too.
 32301     loewis         if isinstance(input, unicode):
 32301     loewis             labels = dots.split(input)
 32301     loewis         else:
 32301     loewis             # Must be ASCII string
 32301     loewis             unicode(input, "ascii")
 32301     loewis             labels = input.split(".")

but the py3k port, r55215, was clearly incomplete and the log message is explicit about it:


r55215 | guido.van.rossum | 2007-05-09 19:40:37 -0400 (Wed, 09 May 2007) | 3 lines

Random modifications that slightly improve the chances of this not blowing up.
Walter will fix it for real.

I hope I picked the right Walter for the "nosy" list.

Arguably, it is not a bug if codec's decode method rejects unicode strings with a TypeError.  The 2.x implementation seems to allow decoding of ASCII-only unicode labels joined by arbitrary RFC 3490 separators.  I am not sure what the use case for this behavior would be.  In any case, supporting this would be a feature and it's acceptance would depend on the outcome of #7475.

> Arguably, it is not a bug if codec's decode method rejects unicode
> strings with a TypeError.

Agreed, but it would be better if it did so deliberately and explicitly, rather than as a result of a bogus forward-port ;)

I agree that the codec shouldn't "decode" unicode strings. However, the operation performed is still meaningful: users may type ACE (ascii-compatibly-encoded) DNS names into a user interface, and the application may then represent this as a "proper" Unicode name.

So I propose these changes:

- remove support for bytes in codec, but only so for 3.3 (it's actually no change in behavior, since it will continue to raise TypeErrors)
- add a function decode_idna to the module, for users that wish to un-IDNA string objects.

+1.  decode_idna is likely to be useful to the email package.