[issue44329] [sqlite3] refactor pysqlite_statement_create

2021-06-08 Thread Erlend E. Aasland
Change by Erlend E. Aasland : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue44329] [sqlite3] refactor pysqlite_statement_create

2021-06-08 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: New changeset 1c02655fb08043b3027748ca1179c416c21a4277 by Erlend Egeberg Aasland in branch 'main': bpo-44329: Refactor sqlite3 statement creation (GH-26566) https://github.com/python/cpython/commit/1c02655fb08043b3027748ca1179c416c21a4277 --

[issue44329] [sqlite3] refactor pysqlite_statement_create

2021-06-06 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: > Yes, we need to allocate/track every time. I just propose to do so as late as > possible, in order to avoid allocating a PyObject before we know if it is > possible to actually create the statement. That describes much better the intent :)

[issue44329] [sqlite3] refactor pysqlite_statement_create

2021-06-06 Thread Erlend E. Aasland
Erlend E. Aasland added the comment: Ah, I see I formulated myself a bit unclear: Yes, we need to allocate/track every time. I just propose to do so as late as possible, in order to avoid allocating a PyObject before we know if it is possible to actually create the statement. -- ___

[issue44329] [sqlite3] refactor pysqlite_statement_create

2021-06-06 Thread Erlend E. Aasland
Erlend E. Aasland added the comment: ... to expand: so currently, if statement creation fails, we must deallocate the PyObject. -- ___ Python tracker ___

[issue44329] [sqlite3] refactor pysqlite_statement_create

2021-06-06 Thread Erlend E. Aasland
Erlend E. Aasland added the comment: > I am not sure what you mean, in the happy path you still need to GC track and > allocate. Currently, we allocate the object, then try to create the statement using the SQLite API. If we create the statement first, we can do the sanity check on the retu

[issue44329] [sqlite3] refactor pysqlite_statement_create

2021-06-06 Thread Pablo Galindo Salgado
Pablo Galindo Salgado added the comment: > will avoid unneeded allocations/GC tracking, I am not sure what you mean, in the happy path you still need to GC track and allocate. -- nosy: +pablogsal ___ Python tracker

[issue44329] [sqlite3] refactor pysqlite_statement_create

2021-06-06 Thread Erlend E. Aasland
Change by Erlend E. Aasland : -- keywords: +patch pull_requests: +25155 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26566 ___ Python tracker __

[issue44329] [sqlite3] refactor pysqlite_statement_create

2021-06-06 Thread Erlend E. Aasland
New submission from Erlend E. Aasland : Currently, pysqlite_statement_create() approx. looks like this: 1. some sanity checks (type, sql lenght, etc.) 2. allocate (PyObject_GC_New) 3. initialise members 4. determine if statement is a DML statement 5. create the statement (sqlite3_prepare_v2) 6.