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 <[email protected]>
<http://bugs.python.org/issue29259>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
