Hello,
I have one implementation question about vectorcall which is not
specified in PEP 590: what should happen if a type implements vectorcall
(i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but doesn't set tp_call (i.e.
tp_call == NULL)? I see the following possibilities:
1. Ignore this problem
Hi Montana,
As Cameron Simpson already pointed out, your query is off-topic for the
Python-Dev mailing list and should be taken to the Python-Ideas mailing
list, which is for speculative discussion of new designs.
Like Cameron, I've CCed Python-Ideas. Please send any follow-ups to that
list an
Hi, all.
Yury implemented per opcode cache for LOAD_GLOBAL,
LOAD_ATTR, and LOAD_METHOD. [1]
I update the patch for current master branch, but only for
LOAD_GLOBAL for now. [2] It sped up LOAD_GLOBAL
about 40%. [3] It is attractive optimization.
Now 3.8b1 will be coming soon, but the pull requ
On 5/29/19 2:25 PM, Jeroen Demeyer wrote:
Hello,
I have one implementation question about vectorcall which is not
specified in PEP 590: what should happen if a type implements vectorcall
(i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but doesn't set tp_call (i.e.
tp_call == NULL)? I see the follow
On 2019-05-29 15:29, Petr Viktorin wrote:
That sounds like a good idea for PyType_FromSpec.
I don't think we're planning to support vectorcall in PyType_FromSpec
for now. That's maybe for 3.9 when vectorcall is no longer provisional.
For static types I either wouldn't bother at all, or only
On 29/05/2019 15.29, Petr Viktorin wrote:
> On 5/29/19 2:25 PM, Jeroen Demeyer wrote:
>> Hello,
>>
>> I have one implementation question about vectorcall which is not
>> specified in PEP 590: what should happen if a type implements
>> vectorcall (i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but doesn't
On 2019-05-29 16:00, Christian Heimes wrote:
You could add a check to PyType_Ready() and have it either return an
error or fix tp_call.
Yes, but the question is: which of these two alternatives? I would vote
for fixing tp_call but Petr voted for an error.
_
On Wed, 29 May 2019 at 16:08, Greg Ewing wrote:
>
> Nick Coghlan wrote:
> > Having a single locals() call de-optimize an entire function would be
> > far from ideal.
>
> I don't see what would be so bad about that. The vast majority
> of functions have no need for locals().
If there was a compell
On Wed, May 29, 2019 at 6:21 AM Inada Naoki wrote:
> Hi, all.
>
> Yury implemented per opcode cache for LOAD_GLOBAL,
> LOAD_ATTR, and LOAD_METHOD. [1]
>
> I update the patch for current master branch, but only for
> LOAD_GLOBAL for now. [2] It sped up LOAD_GLOBAL
> about 40%. [3] It is attract
On Wed, May 29, 2019 at 7:55 AM Jeroen Demeyer wrote:
> On 2019-05-29 16:00, Christian Heimes wrote:
> > You could add a check to PyType_Ready() and have it either return an
> > error or fix tp_call.
>
> Yes, but the question is: which of these two alternatives? I would vote
> for fixing tp_call
On 5/29/19 3:36 PM, Jeroen Demeyer wrote:
On 2019-05-29 15:29, Petr Viktorin wrote:
That sounds like a good idea for PyType_FromSpec.
I don't think we're planning to support vectorcall in PyType_FromSpec
for now. That's maybe for 3.9 when vectorcall is no longer provisional.
For static typ
Nick Coghlan wrote:
If there was a compelling use case for letting "a = 1; exec(src);
print(a)" print something other than "1" at function scope, then I'd
be more amenable to the idea of the associated compatibility break and
potential performance regression in other implementations.
However, th
12 matches
Mail list logo
