This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients methane, serhiy.storchaka, vstinner
Date 2017-01-13.16:48:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1484326121.82.0.264560375132.issue29259@psf.upfronthosting.co.za>
In-reply-to
Content
Ok, I pushed a new commit "Add Py_TPFLAGS_HAVE_FASTCALL flag" in my Git branch.

(By the way, I'm using the Git branch as a working copy, it can change anytime to get a nice list of commits. If you want reliable changes, use patches attached to this issue.)


Serhiy Storchaka!:
> For compatibility with extensions built with older Pythons you should define new type flag and read tp_fastcall only if the flag is set. See for example Py_TPFLAGS_HAVE_FINALIZE.

Wait, there is maybe an issue with the stable API in my design :-/

Let's say that a builtin type NEW defines tp_fastcall and uses fastcall_wrapper() for tp_call. A type OLD inherits from NEW and don't override tp_call (not tp_fastcall). Type OLD comes from an extension compiled with Python 3.6 and use the stable ABI. Does the type OLD contain the field tp_fastcall in memory? Is it possible to copy the tp_fastcall filed from type NEW into the type OLD?

If not, the fastcall_wrapper() should be smarter to not get tp_fastcall from the type OLD but follow the MRO to find the first type with the Py_TPFLAGS_HAVE_FASTCALL flag. Is it possible that this short loop to find has a cost on performances?
History
Date User Action Args
2017-01-13 16:48:41vstinnersetrecipients: + vstinner, methane, serhiy.storchaka
2017-01-13 16:48:41vstinnersetmessageid: <1484326121.82.0.264560375132.issue29259@psf.upfronthosting.co.za>
2017-01-13 16:48:41vstinnerlinkissue29259 messages
2017-01-13 16:48:41vstinnercreate