STINNER Victor added the comment: > * If a type only defines tp_fastcall: tp_fastcall is always use (tp_call uses > the wrapper) > > Is tp_call set to the wrapper rather then inheriting?
It is set to the wrapper. Defining tp_fastcall should work as defining tp_call: it should override the tp_call and tp_fastcall slots. > What if tp_call is defined in a superclass? What is a superclass? Do you have an example? > * If a type defines tp_call and tp_fastcall, PyObject_Call() uses tp_call > whereas _PyObject_FastCallDict() uses tp_fastcall. > > I would consider this as a bug. It would be weird if different ways of > calling cause executing different code. It's a micro-optimization to avoid arguments unpacking/packing, conversions needed when you switch from the regular calling convention to the fast call convention, or the opposite. I don't think that types defining tp_call and tp_fastcall will be common. > What about dynamically changed Python types? What do you mean? Do you have an example? > What if you set or delete the __call__ attribute of Python class? I don't know how these things work :-) Let me try on a patched Python (using tp_fastcall): $ ./python >>> class A: ... def __call__(self): print("A") ... >>> a=A() >>> a() A >>> A.__call__=lambda self: print("B!") >>> a() B! >>> del A.__call__ >>> a() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'A' object is not callable It seems like "it just works", but I don't know how it works internally :-) a() uses a dynamic lookup of a.__class__.__call__, no? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29259> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com