[issue45774] Detect SQLite in configure.ac
Erlend E. Aasland added the comment: Reopening: the current detection is a little bit weak; many SQLite API's may be disabled at SQLite compile time using SQLITE_OMIT_* defines. We must make sure we've got all vital functions in place before marking the sqlite3 module as present and usable. The following API's can be omitted using compile time defines: - sqlite3_column_decltype (SQLITE_OMIT_DECLTYPE) - sqlite3_complete (SQLITE_OMIT_COMPLETE) - sqlite3_enable_shared_cache (SQLITE_OMIT_SHARED_CACHE) - sqlite3_progress_handler (SQLITE_OMIT_PROGRESS_CALLBACK) - sqlite3_set_authorizer (SQLITE_OMIT_AUTHORIZATION) - sqlite3_trace_v2 (SQLITE_OMIT_TRACE) - sqlite3_trace (SQLITE_OMIT_TRACE, SQLITE_OMIT_DEPRECATED) The following API's _may_ be disabled in the future using SQLITE_OMIT_FLOATING_POINT: - sqlite3_bind_double - sqlite3_column_double - sqlite3_result_double - sqlite3_value_double -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue45774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45774] Detect SQLite in configure.ac
Change by Erlend E. Aasland : -- pull_requests: +28240 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/30016 ___ Python tracker <https://bugs.python.org/issue45774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45723] Improve and simplify configure.ac checks
Change by Erlend E. Aasland : -- pull_requests: +28248 pull_request: https://github.com/python/cpython/pull/30024 ___ Python tracker <https://bugs.python.org/issue45723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45723] Improve and simplify configure.ac checks
Change by Erlend E. Aasland : -- pull_requests: +28251 pull_request: https://github.com/python/cpython/pull/30026 ___ Python tracker <https://bugs.python.org/issue45723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45723] Improve and simplify configure.ac checks
Change by Erlend E. Aasland : -- pull_requests: +28254 pull_request: https://github.com/python/cpython/pull/30029 ___ Python tracker <https://bugs.python.org/issue45723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46100] Simplify readline / editline detection
Erlend E. Aasland added the comment: FWIW, the XCode SDKs for macOS 11 and 12 use the NetBSD editline library. $ grep "NetBSD: readline" /Library/Developer/CommandLineTools/SDKs/MacOSX*.sdk/usr/include/readline/readline.h /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/readline/readline.h:/* $NetBSD: readline.h,v 1.33 2012/05/15 17:30:04 christos Exp $ */ /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/readline/readline.h:/* $NetBSD: readline.h,v 1.33 2012/05/15 17:30:04 christos Exp $ */ /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include/readline/readline.h:/* $NetBSD: readline.h,v 1.33 2012/05/15 17:30:04 christos Exp $ */ /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/readline/readline.h:/* $NetBSD: readline.h,v 1.33 2012/05/15 17:30:04 christos Exp $ */ /Library/Developer/CommandLineTools/SDKs/MacOSX12.0.sdk/usr/include/readline/readline.h:/* $NetBSD: readline.h,v 1.33 2012/05/15 17:30:04 christos Exp $ */ /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/readline/readline.h:/* $NetBSD: readline.h,v 1.33 2012/05/15 17:30:04 christos Exp $ */ $ grep RL_READLINE_VERSION /Library/Developer/CommandLineTools/SDKs/MacOSX*.sdk/usr/include/readline/readline.h /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/readline/readline.h:#define RL_READLINE_VERSION 0x0402 /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/readline/readline.h:#define RL_READLINE_VERSION 0x0402 /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk/usr/include/readline/readline.h:#define RL_READLINE_VERSION 0x0402 /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk/usr/include/readline/readline.h:#define RL_READLINE_VERSION 0x0402 /Library/Developer/CommandLineTools/SDKs/MacOSX12.0.sdk/usr/include/readline/readline.h:#define RL_READLINE_VERSION 0x0402 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include/readline/readline.h:#define RL_READLINE_VERSION 0x0402 This is what Homebrew provides: $ PKG_CONFIG_PATH=$(brew --prefix readline)/lib/pkgconfig pkg-config readline --cflags --libs -I/usr/local/Cellar/readline/8.1.1/include -L/usr/local/Cellar/readline/8.1.1/lib -lreadline -- ___ Python tracker <https://bugs.python.org/issue46100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46100] Simplify readline / editline detection
Erlend E. Aasland added the comment: > I propose to simplify the checks and require a readline 4.2 compatible API. +1 BTW: > GNU readline was released in 2001 (20 years ago). FTR, GNU Readline _4.2_ was released in 2001 ;) -- ___ Python tracker <https://bugs.python.org/issue46100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46070] _PyImport_FixupExtensionObject() regression causing a crash in subintepreters
Erlend E. Aasland added the comment: FWIW, I've managed to reproduce once with win_py399_crash_reproducer.py on macOS 12.1 (with very high load average). With bug.py, I can reproduce almost always (more than 90% of the time). -- nosy: +erlendaasland ___ Python tracker <https://bugs.python.org/issue46070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46185] Python 3.10.1 installer refers to /Applications/Python 3.9 Install Certificates
Change by Erlend E. Aasland : -- keywords: +patch nosy: +erlendaasland nosy_count: 2.0 -> 3.0 pull_requests: +28494 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30278 ___ Python tracker <https://bugs.python.org/issue46185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46185] Python 3.10.1 installer refers to /Applications/Python 3.9 Install Certificates
Change by Erlend E. Aasland : -- pull_requests: +28496 pull_request: https://github.com/python/cpython/pull/30280 ___ Python tracker <https://bugs.python.org/issue46185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46185] Python 3.10.1 installer refers to /Applications/Python 3.9 Install Certificates
Erlend E. Aasland added the comment: Thanks for the report, Jaap, and thanks Łukasz for merging :) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46192] Optimize builtin functions min() and max()
Erlend E. Aasland added the comment: Repeating my comment on GH-30286: If we are touching `min()` and `max()`, it would make sense, IMO, to port them to Argument Clinic. FTR, Argument Clinic got `*args` support in GH-18609 / bpo-20291. @colorfulappl made a "competing" branch using AC on his local fork[^1]. However, that branch contained a bug with the key function; I made an amended version[^2] for benchmarking. Here's some micro-benchmarks from optimised builds on macOS 12.1 w/Clang 13: ``` +-+-+---+--+ | Benchmark | main| GH-30286 | GH-30286-ac | +=+=+===+==+ | max(a, b) | 193 ns | 74.1 ns: 2.60x faster | 179 ns: 1.08x faster | +-+-+---+--+ | max(a, b, c, d, e) | 273 ns | 126 ns: 2.17x faster | 260 ns: 1.05x faster | +-+-+---+--+ | max([a, b]) | 267 ns | 185 ns: 1.44x faster | 239 ns: 1.12x faster | +-+-+---+--+ | max([a, b, c, d, e])| 345 ns | 259 ns: 1.33x faster | 312 ns: 1.10x faster | +-+-+---+--+ | max((a,), (b,), key=lambda x: x[0]) | 707 ns | 444 ns: 1.59x faster | 513 ns: 1.38x faster | +-+-+---+--+ | max((a,), (b,), (c,), (d,), (e,), key=lambda x: x[0]) | 1.12 us | 831 ns: 1.35x faster | 930 ns: 1.20x faster | +-+-+---+--+ | max([(a,), (b,)], key=lambda x: x[0]) | 786 ns | 561 ns: 1.40x faster | 570 ns: 1.38x faster | +-+-+---+--+ | max([(a,), (b,), (c,), (d,), (e,)], key=lambda x: x[0]) | 1.19 us | 981 ns: 1.22x faster | 981 ns: 1.22x faster | +-+-+---+--+ | max([], default=-1) | 484 ns | 177 ns: 2.73x faster | 188 ns: 2.57x faster | +-+-+---+--+ | Geometric mean | (ref) | 1.68x faster | 1.29x faster | +-+-+---+--+ ``` [^1]: https://github.com/colorfulappl/cpython/commit/29b9559de31ae19e8d127d7a3063494b2d9791b0 [^2]: https://github.com/erlend-aasland/cpython/tree/gh-30286-ac -- nosy: +erlendaasland Added file: https://bugs.python.org/file50528/bench-minmax.py ___ Python tracker <https://bugs.python.org/issue46192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46212] Avoid temporary `varargs` tuple creation in argument passing
Erlend E. Aasland added the comment: Note that _PyArg_UnpackKeywordsWithVararg is defined with PyAPI_FUNC. Changing its argument spec is strictly a backwards incompatible change, IIUC. -- nosy: +BTaskaya ___ Python tracker <https://bugs.python.org/issue46212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.1
Erlend E. Aasland added the comment: SQLite 3.37.1 appeared the day before New Years Eve. So let us wait until the end of January before upgrading the installers. https://www.sqlite.org/releaselog/3_37_1.html -- title: Upgrade macOS and Windows installers to use SQLite 3.37.0 -> Upgrade macOS and Windows installers to use SQLite 3.37.1 ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
Erlend E. Aasland added the comment: FYI, I'm maintaining a rebased version on my fork: https://github.com/erlend-aasland/cpython/tree/sqlite-blob Here's the changes I've applied upon PR 271: - Use Argument Clinic - Convert to heap types - Adopt new CPython C APIs (Py_NewRef, Py_Is*, new slice API, etc.) - Lint code (PEP 7, use CPython idioms, normalise variable and helper namings) - Lint docs - Normalise error messages - Refactor very large functions, apply simplifications, and remove unneeded code - Expand test suite to increase code coverage I don't think it is ready for inclusion yet; the test suite needs to be restructured, or maybe rewritten from scratch. Pr. now most of the tests maintain a single connection with a prepared database. IMO, it's a fragile design and it is hard to read, debug, and verify the test code. I'll see if I can get to it in a couple of weeks. -- ___ Python tracker <https://bugs.python.org/issue24905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46200] Discourage logging f-strings due to security considerations
Change by Erlend E. Aasland : -- nosy: +erlendaasland ___ Python tracker <https://bugs.python.org/issue46200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
Change by Erlend E. Aasland : -- pull_requests: +28570 pull_request: https://github.com/python/cpython/pull/30356 ___ Python tracker <https://bugs.python.org/issue24905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
Erlend E. Aasland added the comment: I've submitted my changes as a separate PR. I believe we should consider duplicating the apsw API, for users convenience. Pr. now, they are very similar, except for the "open blob" API: apsw uses `blobopen`, we currently use `open_blob`. I suggest changing it to `blobopen`. -- ___ Python tracker <https://bugs.python.org/issue24905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
Erlend E. Aasland added the comment: The diff is pretty heavy, here's the diffstat: 17 files changed, 1362 insertions(+), 7 deletions(-) It will be hard to find reviewers for such a large PR. I suggest to remove mapping support and context manager support for now, and then add those features in separate PR's. -- ___ Python tracker <https://bugs.python.org/issue24905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
Erlend E. Aasland added the comment: Slimmed PR diff (excluding clinic), without context manager and mapping protocol: $ git diff main Modules/_sqlite/*.[ch] Lib Doc Misc PC* setup.py Doc/includes/sqlite3/blob.py | 12 + Doc/includes/sqlite3/blob_with.py | 12 + Doc/library/sqlite3.rst | 73 ++ Doc/whatsnew/3.11.rst | 4 + Lib/test/test_sqlite3/test_dbapi.py | 165 +- Misc/NEWS.d/next/Library/2018-04-18-16-15-55.bpo-24905.jYqjYx.rst | 3 + Modules/_sqlite/blob.c| 342 + Modules/_sqlite/blob.h| 24 ++ Modules/_sqlite/connection.c | 83 ++- Modules/_sqlite/connection.h | 5 +- Modules/_sqlite/module.c | 6 +- Modules/_sqlite/module.h | 1 + PCbuild/_sqlite3.vcxproj | 2 + PCbuild/_sqlite3.vcxproj.filters | 6 + setup.py | 1 + 15 files changed, 733 insertions(+), 6 deletions(-) Looks promising. -- ___ Python tracker <https://bugs.python.org/issue24905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
Change by Erlend E. Aasland : -- Removed message: https://bugs.python.org/msg409590 ___ Python tracker <https://bugs.python.org/issue24905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
Erlend E. Aasland added the comment: Slimmed PR diff (excluding clinic), without context manager and mapping protocol: $ git diff main Modules/_sqlite/*.[ch] Lib Doc Misc PC* setup.py Doc/includes/sqlite3/blob.py | 12 + Doc/includes/sqlite3/blob_with.py | 12 + Doc/library/sqlite3.rst | 73 ++ Doc/whatsnew/3.11.rst | 4 + Lib/test/test_sqlite3/test_dbapi.py | 165 +- Misc/NEWS.d/next/Library/2018-04-18-16-15-55.bpo-24905.jYqjYx.rst | 3 + Modules/_sqlite/blob.c| 342 + Modules/_sqlite/blob.h| 24 ++ Modules/_sqlite/connection.c | 83 ++- Modules/_sqlite/connection.h | 5 +- Modules/_sqlite/module.c | 6 +- Modules/_sqlite/module.h | 1 + PCbuild/_sqlite3.vcxproj | 2 + PCbuild/_sqlite3.vcxproj.filters | 6 + setup.py | 1 + 15 files changed, 733 insertions(+), 6 deletions(-) Looks promising. -- ___ Python tracker <https://bugs.python.org/issue24905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
Erlend E. Aasland added the comment: (the bpo bot is obviously confused by the News entry path, sigh) -- ___ Python tracker <https://bugs.python.org/issue24905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33376] [pysqlite] Duplicate rows can be returned after rolling back a transaction
Erlend E. Aasland added the comment: GH-26026 / bpo-44092 has removed the old workaround where pending statements were reset before a rollback. Since version 3.7.11, SQLite no longer has any issues with pending statements and rollbacks, so we remove the workaround, since we require SQLite 3.7.15 or newer in CPython. As a side effect, pysqlite_do_all_statements() has now been removed, as it is unused code. Following GH-26026, this issue is no longer an issue; I close it as fixed. Ma Lin: if you have problems with the LRU cache, please open a new issue. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33376] [pysqlite] Duplicate rows can be returned after rolling back a transaction
Change by Erlend E. Aasland : -- pull_requests: -12242 ___ Python tracker <https://bugs.python.org/issue33376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop
New submission from Erlend E. Aasland : The query loop in _pysqlite_query_execute() is run only once for ordinary execute()'s, but multiple times for executemany(). We use the 'multiple' variable to differ between the two execute methods; for execute(), multiple is false, for executemany(), multiple is true. At the end of the loop, the 'lastrowid' connection attribute is set, if multiple is false. We can safely move this part out of the loop; it is irrelevant for executemany(), and it will only be run once for execute(). -- assignee: erlendaasland components: Extension Modules messages: 409620 nosy: erlendaasland priority: normal severity: normal status: open title: [sqlite3] move set lastrowid out of the query loop type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop
Change by Erlend E. Aasland : -- keywords: +patch pull_requests: +28583 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30371 ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44092] [sqlite3] Remove special rollback handling
Erlend E. Aasland added the comment: Reopening; there's some clean-up left. After GH-26026, the `reset` member of `pysqlite_Cursor` is now unused. We can remove it and all related code. PR coming. -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue44092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44092] [sqlite3] Remove special rollback handling
Change by Erlend E. Aasland : -- pull_requests: +28587 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/30377 ___ Python tracker <https://bugs.python.org/issue44092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44958] [sqlite3] only reset statements when needed
Change by Erlend E. Aasland : -- pull_requests: +28589 pull_request: https://github.com/python/cpython/pull/30379 ___ Python tracker <https://bugs.python.org/issue44958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop
Erlend E. Aasland added the comment: I see that PEP 249 does not define the semantics of lastrowid for executemany(). What's the precedence here, MAL? IMO, it would be nice to be able to fetch the last row id after you've done a 1000 inserts using executemany(). So, another option would be to keep "set-lastrowid" in the query loop, and just remove the condition; we set it every time (but of course only build a PyObject of it when the loop is done). -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44092] [sqlite3] Remove special rollback handling
Change by Erlend E. Aasland : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop
Change by Erlend E. Aasland : -- pull_requests: +28590 pull_request: https://github.com/python/cpython/pull/30380 ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop
Erlend E. Aasland added the comment: > So, another option would be to keep "set-lastrowid" in the query loop, and > just remove the condition; we set it every time (but of course only build a > PyObject of it when the loop is done). I made a competing PR (GH-30380) for this, just a little better (IMO); the Py object is only built on demand :) -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44092] [sqlite3] Remove special rollback handling
Change by Erlend E. Aasland : -- pull_requests: +28591 pull_request: https://github.com/python/cpython/pull/30381 ___ Python tracker <https://bugs.python.org/issue44092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop
Erlend E. Aasland added the comment: Thank you for your input Marc-André. For SQLite, it's pretty simple: we use an API called sqlite3_last_insert_rowid() which takes the database connection as it's argument, not a statement pointer. This function returns "the rowid of the most recent successful INSERT into a rowid table or virtual table on database connection" (quote from SQLite docs). IMO, it would make sense to also use this post executemany(). -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop
Erlend E. Aasland added the comment: > If possible, it's usually better to have the .executemany() create a > cursor with an output array providing the row ids, e.g. using "INSERT ... > RETURNING ..." (PostgreSQL). That way you can access all row ids and > can also provide the needed detail in case the INSERTs happen out of > order to map them to the input data. Hm, maybe so. But it will add a lot of overhead and complexity to executemany(), and there haven't been requests for this feature for sqlite3. AFAIK, there hasn't been request for lastrowid for executemany() at all. OTOH, my proposal of modifying lastrowid to always show the rowid of the actual last inserted row is a very cheap operation, _and_ it simplifies the code (=> increased maintainability), so I think I'll go for that. > For cases where you don't need sequence IDs, it's often better to > not rely on auto-increment columns for IDs, but instead use random > pre-generated IDs. Saves roundtrips to the database and works nicely > with cluster databases as well. Yes, but in those cases you keep track of the row id yourself, so you probably won't need lastrowid ;) -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop
Erlend E. Aasland added the comment: True that :) I'll close GH-30371 and prepare GH-30380 for review. I'll request your review if you don't mind. -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()
Change by Erlend E. Aasland : -- title: [sqlite3] move set lastrowid out of the query loop -> [sqlite3] move set lastrowid out of the query loop and enable it for executemany() ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()
Erlend E. Aasland added the comment: There are some inaccuracies in the docs I need to fix first, since those changes must be backported, and I want the updated docs applied upon the corrected docs; I'll open a separate issue/PR for that. -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46261] [doc] fix inaccuracies in sqlite3.Cursor.lastrowid docs
New submission from Erlend E. Aasland :
The sqlite3 docs say that lastrowid is set to None after executemany(), or
after execute()'ing statements that are not INSERTs or REPLACEs. This is not
true; in those cases, lastrowid is preserved. lastrowid is only None in a
pristine cursor. Suggesting to reword the docs so they harmonise with the
implementation.
Note, there is a quirk, or bug with lastrowid: it is set to 0 if the first
statement that's execute()d on a cursor is a non-INSERT/REPLACE statement. For
example:
>>> import sqlite3
>>> cx = sqlite3.connect(":memory:")
>>> cu = cx.cursor()
>>> cu.lastrowid
>>> cu.execute("select 1")
>>> cu.lastrowid
0
This behaviour is consistent across current main through 3.7 (though in 2.7,
the behaviour is consistent with the docs, so it probably changed a long time
ago). I'm not sure it's worth noting this side effect in the docs though.
--
assignee: docs@python
components: Documentation
messages: 409713
nosy: docs@python, erlendaasland, lemburg
priority: normal
severity: normal
status: open
title: [doc] fix inaccuracies in sqlite3.Cursor.lastrowid docs
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46261>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46261] [doc] fix inaccuracies in sqlite3.Cursor.lastrowid docs
Erlend E. Aasland added the comment: Oh, and the docs says that lastrowid "provides the rowid of the last modified row". This is not true; it provides the row id of the last _inserted_ row. -- ___ Python tracker <https://bugs.python.org/issue46261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46261] [doc] fix inaccuracies in sqlite3.Cursor.lastrowid docs
Erlend E. Aasland added the comment: I also suggest to add a note about tables without rowids, quoting the SQLite docs: Inserts into WITHOUT ROWID tables are not recorded. -- ___ Python tracker <https://bugs.python.org/issue46261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46261] [doc] fix inaccuracies in sqlite3.Cursor.lastrowid docs
Change by Erlend E. Aasland : -- keywords: +patch pull_requests: +28613 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30407 ___ Python tracker <https://bugs.python.org/issue46261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46261] [doc] fix inaccuracies in sqlite3.Cursor.lastrowid docs
Erlend E. Aasland added the comment: FYI: https://sqlite.org/c3ref/last_insert_rowid.html -- ___ Python tracker <https://bugs.python.org/issue46261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46268] Buildbot failure for buildbot/AMD64 FreeBSD Non-Debug / Shared 3.x
Erlend E. Aasland added the comment: Duplicate of bpo-46263. -- nosy: +erlendaasland resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> FreeBSD buildbots cannot compile Python ___ Python tracker <https://bugs.python.org/issue46268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: I closed the bug without intention to do so. Sorry for the noise. -- nosy: +erlendaasland resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: FWIW: from test_embed.test_init_setpythonhome: if not config['executable']: config['use_frozen_modules'] = -1 >From the buildbot test stdout (and pythoninfo) I see that config["executable"] >is set to "". -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Change by Erlend E. Aasland : -- Removed message: https://bugs.python.org/msg409774 ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: FWIW: from test_embed.test_init_setpythonhome: if not config['executable']: config['use_frozen_modules'] = -1 >From the buildbot test stdout (but not pythoninfo) I see that >config["executable"] is set to "". -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40601] [C API] Hide static types from the limited C API
Change by Erlend E. Aasland : -- nosy: +erlendaasland ___ Python tracker <https://bugs.python.org/issue40601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)
Erlend E. Aasland added the comment:
In 13915a3100608f011b29da2f3716c990f523b631, the init flag is set before we
even know if module initialisation was successful. Applying the following patch
upon the aforementioned commit (in 3.8) fixes the issue for me on latest Debian:
```
diff --git a/Modules/_asynciomodule.c b/Modules/_asynciomodule.c
index 5261ed3d4c..782138e4e4 100644
--- a/Modules/_asynciomodule.c
+++ b/Modules/_asynciomodule.c
@@ -3250,17 +3250,14 @@ static int
module_init(void)
{
PyObject *module = NULL;
+if (module_initialized) {
+return 0;
+}
asyncio_mod = PyImport_ImportModule("asyncio");
if (asyncio_mod == NULL) {
goto fail;
}
-if (module_initialized != 0) {
-return 0;
-}
-else {
-module_initialized = 1;
-}
current_tasks = PyDict_New();
if (current_tasks == NULL) {
@@ -3322,6 +3319,7 @@ module_init(void)
}
Py_DECREF(module);
+module_initialized = 1;
return 0;
fail:
```
--
___
Python tracker
<https://bugs.python.org/issue46070>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)
Erlend E. Aasland added the comment: > Applying the following patch upon the aforementioned commit (in 3.8) fixes > the issue for me on latest Debian By "the issue", I mean bug.py, not win_py399_crash_reproducer.py. Victor: perhaps we should open a separate issue for the bug.py issue. Applying the patch from msg409795 onto the 3.9 branch also fixes the segfault from bug.py there. main does not segfault for me, but I would apply the patch anyway, since the current code is broken. -- ___ Python tracker <https://bugs.python.org/issue46070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)
Change by Erlend E. Aasland : -- keywords: +patch pull_requests: +28628 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/30423 ___ Python tracker <https://bugs.python.org/issue46070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46070] [subinterpreters] asyncio crash when importing _asyncio in subinterpreter (Python 3.8 regression)
Erlend E. Aasland added the comment: Note, GH-30423 does _not_ fix the win_py399_crash_reproducer.py issue. -- ___ Python tracker <https://bugs.python.org/issue46070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: Marked as a release blocker. See python-committers post: https://mail.python.org/archives/list/python-committ...@python.org/thread/7OWGAL4UL5HNKKQFUGH6N6L4JDVPEN7R/ -- priority: normal -> release blocker ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: Here's a strange observation from my FreeBSD 14.0 VM: With system supplied python3.8 (dependency of the git package), test_embed succeeds. If I explicitly install python3.9 (pkg install python3.9 installs Python 3.9.9), rebuild and test, test_embed fails. -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: FYI, the buildbot has Python 3.9.9 installed, as seen from the configure step. (nit: it's pkg install python39, not pkg install python3.9) -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: Wait a minute. It is not tied to the Python version installed; it seems to be an issue with in-tree vs. out-of-tree builds. The failed build was in-tree. The build that succeeded was out-of-tree. I did a new build with Python 3.9 installed, which succeeded out-of-tree. To clear things up: - out-of-tree build with system Python 3.8 => succeeds - out-of-tree build with system Python 3.9 => succeeds - in-tree build with system Python 3.9 => fails -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: FTR: - in-tree build with system Python 3.8 => fails -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: > Note that in-tree builds are working find on other platforms, AFAICS. Yes, almost all of the buildbots are using in-tree builds. IIRC, buildbots for out-of-tree builds were added just recently. -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: AFAICS, the test_embed failure first appeared after GH-29041 (bpo-45582) was merged. After GH-29041, there has been numerous fixes for test_embed: $ git log --oneline | grep bpo-45582 3f398a77d3 bpo-45582: Fix test_embed failure during a PGO build on Windows (GH-30014) b0b3086279 bpo-45582: Write empty pybuilddir.txt on Windows to allow relocatable build directories (GH-29979) 06c4ae8b13 bpo-45582: Fix framework path and bootstrap build (GH-29954) b7ef27bc08 bpo-45582: Ensure PYTHONHOME still overrides detected build prefixes (GH-29948) f16f93e527 bpo-45582: framework build: modPath must not be const (GH-29944) af1db4eb55 bpo-45582: Fix getpath_isxfile() and test_embed on Windows (GH-29930) 628abe4463 bpo-45582: Fix signature of _Py_Get_Getpath_CodeObject (GH-29921) 0ae4e0c959 bpo-45582 Fix prototype of _Py_Get_Getpath_CodeObject. (GH-29907) 7d7c91a8e8 bpo-45582: Add a NOT operator to the condition in getpath_isxfile (GH-29906) ccb73a0d50 bpo-45582: Fix out-of-tree build issues with new getpath (GH-29902) 99fcf15052 bpo-45582: Port getpath[p].c to Python (GH-29041) -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: > the test_embed failure first appeared after GH-29041 (bpo-45582) was merged. Make that "first appeared on FreeBSD". Also, numerous was perhaps an exaggeration. Make that a few :) -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: Also, AMD64 FreeBSD Shared 3.x is configured --with-pydebug and --enable-shared. I'd be surprised if those were the root cause of this though. Both buildbots are in-tree builds. FWIW, my FreeBSD 14.0-CURRENT main-n250453-7ac82c96fe7 VM also fails, as noted in previous posts. It's built with just ./configure && make. -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: Great. I tried the same trick on my VM earlier today, but I was unsure if it was the correct fix :) Thanks! -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Change by Erlend E. Aasland : -- status: open -> pending ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.1
Erlend E. Aasland added the comment: SQLite 3.37.2 is fresh out now. Copying the release statement from the SQLite forum: Patch release 3.37.2 fixes a potential database corruption bug. Upgrading is recommended for all users. The database corruption bug is obscure and you are unlikely to hit it. But you should probably still upgrade. For more information about the bug see: * https://sqlite.org/forum/forumpost/ac381d64d8 Link to the release page: https://www.sqlite.org/releaselog/3_37_2.html We should consider backporting to 3.10 and 3.9 due to the severity of the bug. -- ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
Change by Erlend E. Aasland : -- title: Upgrade macOS and Windows installers to use SQLite 3.37.1 -> Upgrade macOS and Windows installers to use SQLite 3.37.2 ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
Erlend E. Aasland added the comment: Quoting the SQLite forum post, regarding backporting: There is a bug in versions 3.35.0 (2021-03-12) through 3.37.1 (2021-12-30) which could potentially cause database corruption. Upgrading to version 3.37.2 (2022-01-06) or later is recommended. The Python 3.10 Windows and macOS installers ship with SQLite 3.36.0, so they are vulnerable to this bug. Ditto for the Python 3.9 Windows and macOS installers which ship with SQLite 3.35.5. -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
Change by Erlend E. Aasland : -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Erlend E. Aasland added the comment: Both FreeBSD bots are green again. Thank you Christian and Eric! -- priority: release blocker -> resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
Erlend E. Aasland added the comment: As I understand the forum post, you're vulnerable if you use that specific build option (we don't), _or_ if you use the pragma (anyone may do that). So AFAICS, we should upgrade. -- ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
Erlend E. Aasland added the comment: No, I don’t think we need to rush a new release. The scheduled 3.10 and 3.9 releases should do fine. Can you update the sources repo in the mean time? -- ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46261] [doc] fix inaccuracies in sqlite3.Cursor.lastrowid docs
Change by Erlend E. Aasland : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()
Erlend E. Aasland added the comment: Marc-André: since Python 3.6, the sqlite3.Cursor.lastrowid attribute does no longer comply with the recommendations of PEP 249: Previously, lastrowid was set to None for operations other than INSERT or REPLACE. This changed with ab994ed8b97e1b0dac151ec827c857f5e7277565 (in Python 3.6), so that lastrowid is _unchanged_ for operations other than INSERT or REPLACE, and it is set to 0 after the first valid SQL (that is not INSERT/REPLACE) is executed on the cursor. Now, PEP 249 only _recommends_ that lastrowid is set to None for operations that do not modify a row, so it's probably not a big deal. No-one has ever mentioned this change in behaviour; there have been no bug reports. FTR, here is the relevant quote from PEP 249: If the operation does not set a rowid or if the database does not support rowids, this attribute should be set to None. (I interpret "should" as understood by RFC 2119.) So, my follow-up question becomes: I see no point in reverting to pre Python 3.6 behaviour. I would rather change the default value to be 0 (to get rid of the dirty flag in GH-30380), and to make the behaviour more consistent with how the actual SQLite API behaves. Do you have an opinion about such a change (in behaviour)? -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()
Erlend E. Aasland added the comment: I see now that GH-30380 has grown a little bit out of scope, as it changes too many things at once: 1. Simplify the `execute()`/`executemany()` query loop 2. Create the lastrowid PyObject on demand, simplifying cursor GC 3. `lastrowid` is now available for all `execute*()` methods 4. The default value of `lastrowid` is now `0` It will be easier to reason about and review each change separately. -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()
Change by Erlend E. Aasland : -- pull_requests: +28692 pull_request: https://github.com/python/cpython/pull/30489 ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] lastrowid improvements
Change by Erlend E. Aasland : -- title: [sqlite3] move set lastrowid out of the query loop and enable it for executemany() -> [sqlite3] lastrowid improvements ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46340] DeprecationWarning emitted when running asyncio tests
New submission from Erlend E. Aasland : Providing some more background, based on the changes proposed by Kumar in GH-30486: asyncio.get_event_loop() was marked as deprecated in Python 3.10. Quoting from the asyncio documentation , https://docs.python.org/3/library/asyncio-eventloop.html (as of 3.10): Because this function has rather complex behavior (especially when custom event loop policies are in use), using the get_running_loop() function is preferred to get_event_loop() in coroutines and callbacks. [...] Deprecated since version 3.10: Deprecation warning is emitted if there is no running event loop. In future Python releases, this function will be an alias of get_running_loop(). GH-30486 proposes to replace asyncio.get_event_loop() with asyncio.new_event_loop(). -- nosy: +erlendaasland ___ Python tracker <https://bugs.python.org/issue46340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46340] DeprecationWarning emitted when running asyncio tests
Erlend E. Aasland added the comment: Kumar, did you consider using get_running_loop() to retrieve the event loop in the current thread, instead of creating a new one? -- ___ Python tracker <https://bugs.python.org/issue46340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46340] DeprecationWarning emitted when running asyncio tests
Erlend E. Aasland added the comment: FTR, a rough grep for other users of get_event_loop in Lib/test (some false positives): ``` $ grep -rE "\" Lib/test Lib/test/test_contextlib_async.py:loop = asyncio.get_event_loop_policy().get_event_loop() Lib/test/test_asyncio/test_base_events.py:'loop = asyncio.get_event_loop()', Lib/test/test_asyncio/test_windows_events.py:loop = asyncio.get_event_loop() Lib/test/test_asyncio/test_runners.py:def get_event_loop(self): Lib/test/test_asyncio/test_runners.py:loop = asyncio.get_event_loop() Lib/test/test_asyncio/test_unix_events.py: self.assertIsInstance(policy.get_event_loop(), Lib/test/test_asyncio/test_unix_events.py: policy.get_event_loop().close() Lib/test/test_asyncio/test_unix_events.py:loop = policy.get_event_loop() Lib/test/test_asyncio/test_events.py: self.assertRaises(NotImplementedError, policy.get_event_loop) Lib/test/test_asyncio/test_events.py:loop = policy.get_event_loop() Lib/test/test_asyncio/test_events.py:self.assertIs(loop, policy.get_event_loop()) Lib/test/test_asyncio/test_events.py:loop = policy.get_event_loop() Lib/test/test_asyncio/test_events.py:self.assertRaises(RuntimeError, policy.get_event_loop) Lib/test/test_asyncio/test_events.py: self.assertRaises(RuntimeError, policy.get_event_loop) Lib/test/test_asyncio/test_events.py:old_loop = policy.get_event_loop() Lib/test/test_asyncio/test_events.py:self.assertIs(loop, policy.get_event_loop()) Lib/test/test_asyncio/test_events.py:self.assertIsNot(old_loop, policy.get_event_loop()) Lib/test/test_asyncio/test_events.py:self.get_event_loop_saved = events.get_event_loop Lib/test/test_asyncio/test_events.py:events.get_event_loop = type(self).get_event_loop_impl Lib/test/test_asyncio/test_events.py:asyncio.get_event_loop = type(self).get_event_loop_impl Lib/test/test_asyncio/test_events.py:events.get_event_loop = self.get_event_loop_saved Lib/test/test_asyncio/test_events.py:asyncio.get_event_loop = self.get_event_loop_saved Lib/test/test_asyncio/test_events.py:def get_event_loop(self): Lib/test/test_asyncio/test_events.py: asyncio.get_event_loop() Lib/test/test_asyncio/test_events.py: asyncio.get_event_loop() Lib/test/test_asyncio/test_events.py: self.assertIs(asyncio.get_event_loop(), loop) Lib/test/test_asyncio/test_events.py: asyncio.get_event_loop() Lib/test/test_asyncio/test_events.py: asyncio.get_event_loop() Lib/test/test_asyncio/test_events.py:loop2 = asyncio.get_event_loop() Lib/test/test_asyncio/test_events.py: asyncio.get_event_loop() Lib/test/test_asyncio/test_events.py: self.assertIs(asyncio.get_event_loop(), loop) Lib/test/test_asyncio/test_events.py: self.assertIs(asyncio.get_event_loop(), loop) Lib/test/test_asyncio/test_events.py: asyncio.get_event_loop() ``` -- ___ Python tracker <https://bugs.python.org/issue46340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46340] DeprecationWarning emitted when running asyncio tests
Erlend E. Aasland added the comment: > I think there is no reason to replace all occurrences where get_event_loop() > works fine. +1 I provided the grep for information only, hence FTR (for the record). -- ___ Python tracker <https://bugs.python.org/issue46340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46340] DeprecationWarning emitted when running asyncio tests
Erlend E. Aasland added the comment: > get_event_loop() is deprecated when there is no running event loop. Yes, I see that now. So using asyncio.new_event_loop instead makes sense. -- ___ Python tracker <https://bugs.python.org/issue46340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46331] 3.11: tracing revisits class line after class docstring
Erlend E. Aasland added the comment: I recon this can be closed now? -- nosy: +erlendaasland status: open -> pending ___ Python tracker <https://bugs.python.org/issue46331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()
Erlend E. Aasland added the comment: > Is 0 a valid row ID in SQLite ? If not, then I guess this would be > an alternative to None as suggested by the DB-API. Yes. Any 64 bit signed integer value is a valid row id in SQLite. > If it is a valid row ID, I'd suggest to go back to resetting to None, > since otherwise code might get confused: if an UPDATE does not get > applied (e.g. a condition is false), code could then still take > .lastrowid as referring to the UPDATE and not a previous > operation, since code will now know whether the condition was met > or not. True. OTOH, we've had no requests for reverting to pre Python 3.6 behaviour. If we are to revert to this behaviour, we'll have to start examining the SQL we are given (search for INSERT and REPLACE keywords, determine if they are valid (i.e. not a comment, not part of a column or table name, etc.), which will lead to a noticeable performance hit for every new statement (not for statements reused via the LRU cache though). I'm not sure this is a good idea. However I will give it a good thought. My first thought now, is that it would be better for the sqlite3 module to align lastrowid with the behaviour of the C API sqlite3_last_insert_rowid() (also available as an SQL function: last_insert_rowid). OTOH, the SQLite API is tied to the _connection_ object, so it may not make sense to align it with lastrowid which is a _cursor_ attribute. Perhaps the Right Thing To Do™ is to be conservative and just leave it as it is. I still want to apply the optimisation, though. It does not alter the behaviour in any kind of way, and it speeds up executemany(). -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()
Erlend E. Aasland added the comment: > OTOH, the SQLite API is tied to the _connection_ object, so it may not make > sense to align it with lastrowid which is a _cursor_ attribute. That came out weird; let's try again: The SQLite API is tied to the _connection_ object, so it may not make sense to force that behaviour onto lastrowid which is a _cursor_ attribute. -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()
Erlend E. Aasland added the comment: > You don't know on which cursor the last row was inserted [...] SQLite has no concept of cursors :) > It also seems that the function really only works for INSERTs and > not for UPDATEs. Yes, hence it's name: sqlite3_last_insert_rowid() ! > I'd suggest to deprecate the cursor.lastrowid attribute and > instead point people to the much more useful [...] Yes, I think mentioning the RETURNING ROWID trick in the sqlite3 docs is a very nice improvement. Mentioning the last_insert_rowid SQL function is probably also worth consideration. I'm reluctant to deprecate cursor.lastrowid, though. ATM, I'm leaning towards just keeping the current behaviour. > But this is your call :-) I hear you are saying that, but strictly speaking I'm _not_ the sqlite3 module maintainer; I'm just a very eager contributor :) -- ___ Python tracker <https://bugs.python.org/issue46249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46331] 3.11: tracing revisits class line after class docstring
Change by Erlend E. Aasland : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46314] Stray RESUME opcode for unused lambda
Erlend E. Aasland added the comment: > This fixes the problems I was seeing, thanks. Good; removing release blocker status. Keeping this open until Mark has added a NEWS item. -- nosy: +erlendaasland priority: release blocker -> ___ Python tracker <https://bugs.python.org/issue46314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Erlend E. Aasland added the comment:
FYI, you can already do this using the URI option:
cx = sqlite3.connect("file:test.db?mode=rw", uri=True)
--
___
Python tracker
<https://bugs.python.org/issue46402>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Erlend E. Aasland added the comment: See also bpo-24887. -- ___ Python tracker <https://bugs.python.org/issue46402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Erlend E. Aasland added the comment: IMO, the URI "API" is not very pythonic; I have to look up the format every time I'm using it. OTOH, introducing flags, or keywords, for every option will add a lot of code. -- ___ Python tracker <https://bugs.python.org/issue46402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Erlend E. Aasland added the comment: OTOH, implementing an API similar to apsw (adding a flags keyword) would make it easier for users to switch between that and the stdlib sqlite3. -- ___ Python tracker <https://bugs.python.org/issue46402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Erlend E. Aasland added the comment: I guess we could do more to promote that trick in the docs. It’s quite useful. -- ___ Python tracker <https://bugs.python.org/issue46402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46417] [subinterpreters] Clear static types in Py_Finalize()
Change by Erlend E. Aasland : -- nosy: +erlendaasland ___ Python tracker <https://bugs.python.org/issue46417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Change by Erlend E. Aasland : -- keywords: +patch pull_requests: +28861 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/30660 ___ Python tracker <https://bugs.python.org/issue46402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Erlend E. Aasland added the comment: I created GH-30660 in order to try to enhance the docs. Ned and Eric, would you mind taking a look at the PR? -- ___ Python tracker <https://bugs.python.org/issue46402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Change by Erlend E. Aasland : -- pull_requests: +28871 pull_request: https://github.com/python/cpython/pull/30671 ___ Python tracker <https://bugs.python.org/issue46402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Change by Erlend E. Aasland : -- pull_requests: +28872 pull_request: https://github.com/python/cpython/pull/30672 ___ Python tracker <https://bugs.python.org/issue46402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46402] Enhance sqlite3 to avoid implicit creation?
Erlend E. Aasland added the comment: > BTW, I'm fine with this being closed, since the functionality I wanted is > available and documented. Great. I was considering closing it as soon as the backports have landed (I had to manually fix them bco. make suspicious failures). -- ___ Python tracker <https://bugs.python.org/issue46402> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
