<div dir="auto"><div><br><div class="gmail_quote"><div dir="ltr">2018年6月21日(木) 1:17 Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" target="_blank" rel="noreferrer">solipsis@pitrou.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 20 Jun 2018 18:09:00 +0200<br>
Victor Stinner <<a href="mailto:vstinner@redhat.com" rel="noreferrer noreferrer" target="_blank">vstinner@redhat.com</a>> wrote:<br>
> <br>
> > If we can't at Python 3.7, I think we should do it at 3.8.  <br>
> <br>
> What's the rationale to make it public in 3.7? Can't it wait for 3.8?<br>
> The new PEPs target 3.8 anyway, no?<br>
> <br>
> IMHO it's too late for 3.7.<br>
<br>
Agreed with Victor.  Also Jeroen's work might lead us to change the<br>
protocol for better flexibility or performance.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Unless libraries are written with <span style="font-family:sans-serif">METH_FASTCALL</span> (or using Cython), tp_ccall can't have any gain for 3rd party functions written in C.</div><div dir="auto"><br></div><div dir="auto">In other words, if many libraries start supporting FASTCALL, tp_ccall will have more gain at the time when Python 3.8 is released.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Let's not make it a<br>
public API too early.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Ok.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote></div></div></div>