classification
Title: optionally allow mutable builtin types
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.2
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: gregcouch, loewis, terry.reedy
Priority: normal Keywords: patch

Created on 2005-06-28 18:57 by gregcouch, last changed 2012-06-16 21:23 by terry.reedy. This issue is now closed.

Files
File name Uploaded Description Edit
Python-2.4-wrappy.patch gregcouch, 2005-06-28 18:57 Patch for optional mutable builtin types
Messages (5)
msg48529 - (view) Author: Greg Couch (gregcouch) Date: 2005-06-28 18:57
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.
msg48530 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-07-11 16:44
Logged In: YES 
user_id=21627

Why can't you create such a type as a heap type?
msg48531 - (view) Author: Greg Couch (gregcouch) Date: 2005-07-15 07:26
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.
msg82391 - (view) Author: Greg Couch (gregcouch) Date: 2009-02-18 00:04
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;
}
msg162994 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-06-16 21:23
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.
History
Date User Action Args
2012-06-16 21:23:43terry.reedysetstatus: open -> closed

nosy: + terry.reedy
messages: + msg162994

resolution: out of date
stage: patch review -> resolved
2010-08-21 16:12:32BreamoreBoysetstage: test needed -> patch review
versions: + Python 3.2, - Python 2.7
2009-02-18 00:04:27gregcouchsetmessages: + msg82391
2009-02-16 02:26:06ajaksu2setstage: test needed
type: enhancement
versions: + Python 2.7, - Python 2.4
2005-06-28 18:57:26gregcouchcreate