homepage

Non-heap types, aka builtin types, cannot have their
attributes changed by Python code -- see
Objects/typeobject.c: type_setattro(). This limitation
is good for Python's core builtin types (int, float,
list, dict, ...), but not necessarily for non-heap
types in extension modules. The attached patch allows
for non-heap types to mutate iff the
Py_TPFLAGS_MUTABLE_BUILTIN flag is set.

Logged In: YES 
user_id=21627
Why can't you create such a type as a heap type?

Logged In: YES 
user_id=131838
One reason that the type wasn't a heap type was because I
didn't find an example in the Python documentation. And
because when I was looking through typeobject.c, I saw code,
like type_get_doc(), that ignores the (tp_doc) slot when it
is a heap type -- exactly what I don't want (looking closer,
it may be the only one). I also like most of the
restrictions a non-heap type has, like being unable to
change its name. So if heap types are as fast as non-heap
types, then I have no objection to switching. I'm also
concerned about the additional startup time switching to
heap types would cost since I currently have 75 types in my
module.
The python code that prompted this patch was code that
reached in and added extra keyword arguments to a method,
sort of like a decorator, for additional bookkeeping. 
Subclassing is out because the C (C++) object factory
function only returns the instances of the original type.

FYI, I was able to work around this and use an unmodified Python by
subtyping type and overriding the setattr method as shown below. It's a
lot messier than patching Python.
static int
Mutable_SetAttr(PyObject *obj, PyObject *name, PyObject *value)
{
 // Can't just call PyObject_GenericSetAttr because
 // we need to able to update the __str__ slot as well.
 PyTypeObject *type = reinterpret_cast<PyTypeObject*>(obj);
 type->tp_flags |= Py_TPFLAGS_HEAPTYPE;
 int result = PyType_Type.tp_setattro(obj, name, value);
 type->tp_flags &= ~Py_TPFLAGS_HEAPTYPE;
 return result;
}

Greg, I am closing this because you seem to have found an alternate solution and have dropped the issue. If you do want to pursue a change for 3.4, I suggest you refresh your patch and post to python-ideas (new list since you posted this). As a limited resource, flags are not casually added, and I know another request was recently denied on pydev.