This patch makes sure that the PyHeapTypeObject's ht_name member always contains a PyUnicode_Object.  Other code relies on this.

You're right there's a refcount leak.  Can you rework the patch to avoid this?  One way would be to remove the later INCREF(value) and move that into the code for when value is already a unicode. Then all the error returns from them on must DECREF(value).

Also, the test for null bytes is not correct if there can be non-ASCII characters in the name (as Martin will eventually implement), since it is comparing the strlen() of the 8-bit string (which is UTF-8) with the length of the Unicode string.  I wonder if we shouldn't add a generic API that checks for null characters in a string, as I expect we'll need this in other places too and the correct idiom is much more complicated now.

I also think that you might be able to simply insist on unicode, rather than accepting both string and unicode.  That way we'll find any remaining offenders more quickly (probably there aren't many).

Some test results: with this patch, test_ast fails weirdly:
test test_ast crashed -- <type 'SystemError'>: bad format char passed to Py_BuildValue

I added assert(PyUnicode_Check(value)); to the top of the function and it never triggered during any of the unit tests (I am in a debug build).  So that's a safe assumption.

I did not understand the SystemError in test_ast, but the second version of the patch does not trigger it any longer.  It also does no longer accept PyString in type_set_name, and removes the refcount leak.

The test for null bytes I did not change, a generic api would be great to replace it.
File Added: typeobject.diff

Hm...  Python-ast.c is the *output* of a generating step, according to the top comment.  So that fix ought to be applied somewhere else.

Also, please add XXX in front of the comment "This test is buggy".

Otherwise, looks fine.

The source of make_type is in Parser/asdl_c.py.

The patch's changes to typeobject.c are already in the PEP3137 branch
(but without the "this is buggy" comment), the others are not.

And in the py3k branch as well (r57504).

I'll work on the others and on a fix for the "this is buggy" thing.

Fix for all issues committed as revision 58815 (in the py3k branch).

The strlen() check is replaced by something saner.

Thanks for reminding me!