[Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
INADA Naoki
songofacandy at gmail.com
Wed Jun 20 12:48:23 EDT 2018
More information about the Python-Dev mailing list
Wed Jun 20 12:48:23 EDT 2018
- Previous message (by thread): [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
- Next message (by thread): [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2018年6月21日(木) 1:17 Antoine Pitrou <solipsis at pitrou.net>: > On Wed, 20 Jun 2018 18:09:00 +0200 > Victor Stinner <vstinner at redhat.com> wrote: > > > > > If we can't at Python 3.7, I think we should do it at 3.8. > > > > What's the rationale to make it public in 3.7? Can't it wait for 3.8? > > The new PEPs target 3.8 anyway, no? > > > > IMHO it's too late for 3.7. > > Agreed with Victor. Also Jeroen's work might lead us to change the > protocol for better flexibility or performance. Unless libraries are written with METH_FASTCALL (or using Cython), tp_ccall can't have any gain for 3rd party functions written in C. In other words, if many libraries start supporting FASTCALL, tp_ccall will have more gain at the time when Python 3.8 is released. Let's not make it a > public API too early. > Ok. Even though it's private at 3.7, extension authors can start using it at their risk if we decide METH_FASTCALL is public in 3.8 without any change from 3.7. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180621/8be7c283/attachment.html>
- Previous message (by thread): [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
- Next message (by thread): [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list