Behavior of unicode() builtin is not the same with None as the first argument if we give  the second optional argument.

>>> unicode(None)
u'None'
>>> unicode(None,'ascii')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: coercing to Unicode: need string or buffer, NoneType found

This is confusing.

Maybe, but it is at least documented:
http://docs.python.org/lib/built-in-funcs.html

"If encoding and/or errors are given, unicode()  will decode the object which can either be an 8-bit string or a character buffer using the codec for encoding."

I agree that it's confusing.

The reason is that unicode() with only one argument will use PyObject_Unicode() for the conversion (which then applies some extra logic to turn a non-string argument to a string), while the variant with an encoding will interface to PyUnicode_FromEncodedObject() which only works for strings and character buffers.

I think that all three APIs, PyUnicode_FromObject(), PyUnicode_FromEncodedObject() and PyObject_Unicode() should be unified to use the same logic in their way of converting an object to Unicode. In the light of Py3k, it's probably best to then go with the PyObject_Unicode() approach.

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).