NEURON v9 python syntax does not allow use of template instance name #2860
Comments
|
@ramcdougal I'm stuck on this and could use your help. From what I see in nrnpython/nrnpy_hoc.h the slots are properly filled but the error message generated by and I don't understand why we aren't getting into either hocobj_getitem or hocobj_slice_getitem . Note that if I add a debugging statement in nrnpython/nrnpy_hoc.cpp and with gdb set a breakpoint at the return, then it looks ok with I guess my next debug strategy will be to build a -g version of python and follow what happens on return from hocobj_getattr. |
|
I wonder if this broke with the meaningful types commit... Prior to that, there was no |
|
I believe it did. But it is not directly due to hoc.Vector per se. It happens with any hoc template, e,g hoc.Graph. and but both lines in the code ended up as So I guess I need to look at the |
|
It's just |
|
All these types are created dynamically, I think... So maybe they just need to get a copy of the |
|
I think you are right. From the above casting with (gdb) p *o->ob_type
$12 = {ob_base = {ob_base = {{ob_refcnt = 4294967295, ob_refcnt_split = {
4294967295, 0}}, ob_type = 0x7ffff61735e0 <PyType_Type>},
ob_size = 0}, tp_name = 0x7ffff5fa48f1 "type", tp_basicsize = 920,
tp_itemsize = 40, tp_dealloc = 0x7ffff5de8800 <type_dealloc>,
tp_vectorcall_offset = 400, tp_getattr = 0x0, tp_setattr = 0x0,
tp_as_async = 0x0, tp_repr = 0x7ffff5dea9d0 <type_repr>,
tp_as_number = 0x7ffff6173780 <type_as_number>, tp_as_sequence = 0x0,
tp_as_mapping = 0x0, tp_hash = 0x7ffff5edaf20 <_Py_HashPointer>,
tp_call = 0x7ffff5deaf20 <type_call>, tp_str = 0x7ffff5de4480 <object_str>,
tp_getattro = 0x7ffff5dfc9f0 <_Py_type_getattro>,
tp_setattro = 0x7ffff5df7910 <type_setattro>, tp_as_buffer = 0x0,
tp_flags = 2156420354,
tp_doc = 0x7ffff5fa94c0 <type_doc> "type(object) -> the object's type\ntype(name, bases, dict, **kwds) -> a new type",
tp_traverse = 0x7ffff5de4e80 <type_traverse>,
tp_clear = 0x7ffff5dea5c0 <type_clear>,
tp_richcompare = 0x7ffff5de5120 <object_richcompare>,
tp_weaklistoffset = 368, tp_iter = 0x0, tp_iternext = 0x0,
tp_methods = 0x7ffff6173b20 <type_methods>,
tp_members = 0x7ffff6173f40 <type_members>,
tp_getset = 0x7ffff6173d60 <type_getsets>,
tp_base = 0x7ffff6173440 <PyBaseObject_Type>, tp_dict = 0x0,
tp_descr_get = 0x0, tp_descr_set = 0x0, tp_dictoffset = 264,
--Type <RET> for more, q to quit, c to continue without paging--those are null. |
|
@ramcdougal Do you think it makes sense to do a self reference, i.e. I guess, I'll check what |
|
The following results puzzle me since the and the first few lines of output are |
|
I'm starting to think that the ob_type of h.Vector should be |
|
Types of user define hoc templates are working as in the past. i.e. from neuron import h
h(
"""
begintemplate A
proc init() {
x = 2
}
endtemplate A
"""
)
a = h.A()
print(a)
print(type(a))
print(type(type(a)))
print(h.A[0])
v = h.Vector(3)
print(v)
print(type(v))
print(type(type(v)))
print(h.Vector[0])prints the output |
|
After a very long conversation with chatgpt 3.5, we came up with a pure python example of what I wanted, I.e. % cat temp2.py
class CustomMeta(type):
def __new__(cls, name, bases, dct):
return super().__new__(cls, name, bases, dct)
def __getitem__(cls, index):
print("inside CustomMeta.__getitem__")
return f"{cls}[{index}]"
class Foo(metaclass=CustomMeta):
def __init__(self):
print("Foo.__init__ ", self)
def __getitem__(self, index):
print("inside Foo.__getitem__")
return f"{self}[{index}]"
print("type(Foo) is", type(Foo))
print("Foo[3] is ", Foo[3])
print("Foo()[5] is ", Foo()[5])
% python3 temp2.py
type(Foo) is <class '__main__.CustomMeta'>
inside CustomMeta.__getitem__
Foo[3] is <class '__main__.Foo'>[3]
Foo.__init__ <__main__.Foo object at 0x1001bfe60>
inside Foo.__getitem__
Foo()[5] is <__main__.Foo object at 0x1001bfe60>[5] |
|
Here's the remainder of the conversation where I asked for a c-api version in the context of the nrnpy_hoc.cpp code. It will likely require another long conversation for me to get it working in our context. Now, how would you get that behavior with my original fragment where I
started with
for (auto name: py_exposed_classes) {
ChatGPT
To achieve similar behavior in your original C++ fragment, where you're creating classes using PyType_FromSpecWithBases, you can define a custom metaclass and include a __getitem__ method in that metaclass.
Here's how you can modify your original C++ code to achieve the desired behavior:
// Define the custom metaclass
static PyObject *CustomMeta_getitem(PyObject *cls, PyObject *index) {
const char *cls_name = PyUnicode_AsUTF8(PyUnicode_FromObject(cls));
const char *index_str = PyUnicode_AsUTF8(PyUnicode_FromObject(index));
printf("%s[%s]\n", cls_name, index_str);
Py_RETURN_NONE;
}
static PyMethodDef CustomMeta_methods[] = {
{"__getitem__", CustomMeta_getitem, METH_O, "Get item"},
{NULL, NULL, 0, NULL} /* Sentinel */
};
static PyTypeObject CustomMeta_Type = {
PyVarObject_HEAD_INIT(NULL, 0)
.tp_name = "custom_module.CustomMeta",
.tp_basicsize = sizeof(PyTypeObject),
.tp_flags = Py_TPFLAGS_DEFAULT,
.tp_methods = CustomMeta_methods
};
// Class creation loop
for (auto name: py_exposed_classes) {
// Create the type object for the class
PyTypeObject* pto = (PyTypeObject*) PyType_FromSpecWithBases(&spec, bases);
if (!pto) {
// Handle error
}
// Set the metaclass to CustomMeta
Py_INCREF(&CustomMeta_Type);
pto->tp_base = &CustomMeta_Type;
// Ensure type finalization
if (PyType_Ready(pto) < 0) {
// Handle error
}
// Add the class type to the module
PyModule_AddObject(m, name, (PyObject*)pto);
} |
Version 8.2 and before allows
But with the current master
The text was updated successfully, but these errors were encountered: