Subtyping a non-builtin type in C/C++
Hi
I am trying to create a subclass of a python class, defined in python,
in C++, but I am having some problems. It all boils down to a problem
of finding the base class' type object and according to the PEP (253) I
would also need to figure out the size of the base class instance
structure, but I'm guessing that the latter can't be done in a way that
would allow me to define a structure for my own type.
The following code is what I've tried, which is an adaptation of
http://groups.google.com/group/comp.lang.python/msg/b32952c69182d366
/* import the module that holds the base class */
PyObject *code_module = PyImport_ImportModule("code");
if (!code_module) return;
/* get a pointer to the base class */
PyObject *ic_class = PyMapping_GetItemString(
PyModule_GetDict(code_module),
"InteractiveConsole");
if (!ic_class) return;
/* assign it as base class */
// The next line is the original code, but as far as I can understand
// the docs for Py_BuildValue the code used is equivalent. I find it
// to be clearer as well.
// EmConType.tp_bases = Py_BuildValue("(O)", ic_class);
Py_INCREF(ic_class);
EmConType.tp_bases = ic_class;
if (PyType_Ready(&EmConType) < 0)
This breaks an assertion in the function classic_mro called by
PyType_Ready however, specifically that on line 1000 of typeobject.c:
assert(PyClass_Check(cls)). To get there you need to fail PyType_Check
as well and indeed, at least in the debug build, cls.ob_type.tp_name is
"dict". ic_class appears to be a "classobj" before the call to
PyType_Ready. I would of course much rather have seen that it was a
"type", but I'm not sufficiently well versed in the python guts to know
if this is ok or not.
If anyone could please lend me a clue, I'd be terribly happy about it.
Thanks,
Johan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Subtyping a non-builtin type in C/C++
Martin v. Löwis wrote:
> [EMAIL PROTECTED] schrieb:
> > I am trying to create a subclass of a python class, defined in python,
> > in C++, but I am having some problems.
>
> Is the base class a classic class or a new-style class? Depending on
> the answer, the code you should write varies significantly.
>
> To create a new type, it might be easiest to do the same as the
> interpreter. Take, for example, a look at the code that gets executed
> for new.classobj("Foo", (), {}).
I deleted my post once I realized that I had been setting tp_bases when
I should have been setting tp_base. As it turns out, that's not the end
of my problems.
I have looked in classobject.c, which I hope is the code you are
referring to, but that doesn't really solve my problem since it assumes
you have the correct base pointers and if I did I would be having a
different problem! Anyway, back to the current one:
The class I am trying to subclass is code.InteractiveConsole. With
tp_base set to the result of
PyMapping_GetItemString(PyModule_GetDict(code_module),
"InteractiveConsole"), PyType_Ready fails with an AttributeError with a
"value" of "mro" and looking at the structure in a debugger just before
the call to PyType_Ready makes me think it's corrupted somehow
(nonprintable name and clearly uninitialized fields).
I can however create an instance by calling PyObject_CallFunction on
that object. If I do, it's type (ob_type->tp_name) will be "instance".
Of course, I don't know the python type system that well, but I must
confess I was expecting it to be "code.InteractiveConsole". What gives?
If I then lookup the __class__ attribute of that instance I am back
full circle at the object with the unprintable name and garbage fields.
The head does seem to be valid and if it means anything to someone it's
ob_type->tp_name is "classobj". For several hours I actually wondered
why it wasn't "Type" but I guess it's just a ... subtype of Type.
I guess I should just go to bed.
Johan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Subtyping a non-builtin type in C/C++
[EMAIL PROTECTED] wrote: > > > I am trying to create a subclass of a python class, defined in python, > > > in C++, but I am having some problems. Note to future news group archeologists: I have since learned that that's because it "can't be done", in the sense that there's no defined way that is supposed to work. Of course it could probably be done by reverse engineering what is done by the interpreter and then applying the same steps manually, but it would be a real hack. -- http://mail.python.org/mailman/listinfo/python-list
Interrupting a running python thread
I have embedded a python console in a plugin to a Windows application. I do not control the application, but the plugin is mine. Since the application is not thread-safe, I am push()-ing each line onto a code.InteractiveConsole on the GUI thread. This has the downside that a silly mistake that creates an infinite loop also hangs the GUI, thus preventing you from saving your work or exiting the application in any normal fashion. As a workaround, I've installed a console handler that calls thread.interrupt_main() when control-c is pressed. I should point out that this is done on a new thread. Unfortunately this doesn't work at all. Without returning from the last call to InteractiveConsole.push() or catching the KeyboardInterrupt, the interpreter explodes with a "no current thread" fatal error. I've tried the exact same code at "the real" python prompt and that happily prints: Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt >>> The code used is this infinite loop: a = 0 while a == 0: b = a + 2 What's the secret? The only use of SetConsoleCtrlHandler I could find in the CPython source didn't make me much wiser. Johan -- http://mail.python.org/mailman/listinfo/python-list
naive misuse?
The documentation for PyThreadState_SetAsyncExc says "To prevent naive misuse, you must write your own C extension to call this". Anyone care to list a few examples of such naive misuse? Johan -- http://mail.python.org/mailman/listinfo/python-list
Re: naive misuse? (of PyThreadState_SetAsyncExc)
[EMAIL PROTECTED] wrote: > The documentation for PyThreadState_SetAsyncExc says "To prevent naive > misuse, you must write your own C extension to call this". Anyone care > to list a few examples of such naive misuse? No? I'll take that then as proof that it's impossible to misuse the function. Thanks, Johan -- http://mail.python.org/mailman/listinfo/python-list
