PEP 590: vectorcall without tp_call
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/assume that it won't happen. This would be bad, since callable(obj) would be False even though obj() would succeed. 2. Raise SystemError. 3. Automatically set tp_call to PyVectorcall_Call. I would vote for 3 since it's the most user-friendly option. There is also no way how it could be wrong: it ensures that tp_call and vectorcall are consistent. Any opinions? Jeroen.
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 following possibilities:
1. Ignore this problem/assume that it won't happen. This would be bad, since callable(obj) would be False even though obj() would succeed.
2. Raise SystemError.
3. Automatically set tp_call to PyVectorcall_Call.
I would vote for 3 since it's the most user-friendly option. There is also no way how it could be wrong: it ensures that tp_call and vectorcall are consistent.
That sounds like a good idea for PyType_FromSpec. For static types I either wouldn't bother at all, or only check in debug builds and fail with Py_FatalError.
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 check in debug builds and fail with Py_FatalError.
So basically an assert(...)?
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 types I either wouldn't bother at all, or only check in debug builds and fail with Py_FatalError.
So basically an assert(...)?
Yes. That's the usual way to let C extension authors know they did something wrong.
On 29May2019 1311, Petr Viktorin wrote:
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 types I either wouldn't bother at all, or only check in debug builds and fail with Py_FatalError.
So basically an assert(...)?
Yes. That's the usual way to let C extension authors know they did something wrong.
It's the usual way to let core developers know they did something wrong :) I don't want to reignite the whole debug/release extension build debate again, but I'll point out that it's very common to develop extension modules against the release binaries on Windows, which means you won't see asserts coming from core (because they've been optimised out). So if this is something we're going to detect at runtime regardless of build, using Py_FatalError/abort or raising a SystemError is preferable. Otherwise we'll be forcing users to debug a segfault. Cheers, Steve
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 set tp_call (i.e. tp_call == NULL)? I see the following possibilities:
1. Ignore this problem/assume that it won't happen. This would be bad, since callable(obj) would be False even though obj() would succeed.
2. Raise SystemError.
3. Automatically set tp_call to PyVectorcall_Call.
I would vote for 3 since it's the most user-friendly option. There is also no way how it could be wrong: it ensures that tp_call and vectorcall are consistent.
That sounds like a good idea for PyType_FromSpec.
For static types I either wouldn't bother at all, or only check in debug builds and fail with Py_FatalError.
You could add a check to PyType_Ready() and have it either return an error or fix tp_call. Christian
On Wed, May 29, 2019 at 7:55 AM Jeroen Demeyer <J.Demeyer@ugent.be> 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 but Petr voted for an error.
I also vote for the error so that people are sure they get the semantics they want/expect. If not defining tp_call is a reasonable thing then I would expect it to never have to be set to begin with and that doesn't sound like what anyone wants if we're talking about automatically filling it.
participants (5)
-
Brett Cannon -
Christian Heimes -
Jeroen Demeyer -
Petr Viktorin -
Steve Dower