[Python-Dev] PEP 590: vectorcall without tp_call
Steve Dower
steve.dower at python.org
Fri May 31 12:37:39 EDT 2019
More information about the Python-Dev mailing list
Fri May 31 12:37:39 EDT 2019
- Previous message (by thread): [Python-Dev] PEP 590: vectorcall without tp_call
- Next message (by thread): [Python-Dev] PEP 590: vectorcall without tp_call
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] PEP 590: vectorcall without tp_call
- Next message (by thread): [Python-Dev] PEP 590: vectorcall without tp_call
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list