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
Erlend E. Aasland added the comment:
I recon this can be closed now?
--
nosy: +erlendaasland
status: open -> pending
___
Python tracker
<https://bugs.python.org/issu
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/issu
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
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/te
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/issue46
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
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/issu
Change by Erlend E. Aasland :
--
pull_requests: +28692
pull_request: https://github.com/python/cpython/pull/30489
___
Python tracker
<https://bugs.python.org/issue46
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
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
Change by Erlend E. Aasland :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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/issue45
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
<ht
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 tra
Change by Erlend E. Aasland :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue45925>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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/issu
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
Change by Erlend E. Aasland :
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue46263>
___
___
Python-bugs-list mailing list
Un
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/issu
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
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 :)
--
___
P
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
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.
--
___
Pyt
Erlend E. Aasland added the comment:
FTR:
- in-tree build with system Python 3.8 => fails
--
___
Python tracker
<https://bugs.python.org/issue46263>
___
_
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
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/issue46
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
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 bloc
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/issue46
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/issu
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
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
Change by Erlend E. Aasland :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue40601>
___
___
Python-bugs-list mailing list
Unsubscribe:
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["executab
Change by Erlend E. Aasland :
--
Removed message: https://bugs.python.org/msg409774
___
Python tracker
<https://bugs.python.org/issue46263>
___
___
Python-bug
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&qu
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/i
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 tra
Erlend E. Aasland added the comment:
FYI: https://sqlite.org/c3ref/last_insert_rowid.html
--
___
Python tracker
<https://bugs.python.org/issue46261>
___
___
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/issu
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/issue46
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://bu
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
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
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/issu
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/issue46
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 pro
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
r
Change by Erlend E. Aasland :
--
pull_requests: +28591
pull_request: https://github.com/python/cpython/pull/30381
___
Python tracker
<https://bugs.python.org/issue44
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
Change by Erlend E. Aasland :
--
pull_requests: +28590
pull_request: https://github.com/python/cpython/pull/30380
___
Python tracker
<https://bugs.python.org/issue46
Change by Erlend E. Aasland :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
Change by Erlend E. Aasland :
--
pull_requests: +28589
pull_request: https://github.com/python/cpython/pull/30379
___
Python tracker
<https://bugs.python.org/issue44
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/issu
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 ->
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/issu
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
Change by Erlend E. Aasland :
--
pull_requests: -12242
___
Python tracker
<https://bugs.python.org/issue33376>
___
___
Python-bugs-list mailing list
Unsub
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
Erlend E. Aasland added the comment:
(the bpo bot is obviously confused by the News entry path, sigh)
--
___
Python tracker
<https://bugs.python.org/issue24
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
Change by Erlend E. Aasland :
--
Removed message: https://bugs.python.org/msg409590
___
Python tracker
<https://bugs.python.org/issue24905>
___
___
Python-bug
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
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
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`.
Change by Erlend E. Aasland :
--
pull_requests: +28570
pull_request: https://github.com/python/cpython/pull/30356
___
Python tracker
<https://bugs.python.org/issue24
Change by Erlend E. Aasland :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
<ht
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
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.or
Change by Erlend E. Aasland :
--
pull_requests: +28496
pull_request: https://github.com/python/cpython/pull/30280
___
Python tracker
<https://bugs.python.org/issue46
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.p
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
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 t
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/u
Change by Erlend E. Aasland :
--
pull_requests: +28254
pull_request: https://github.com/python/cpython/pull/30029
___
Python tracker
<https://bugs.python.org/issue45
Change by Erlend E. Aasland :
--
pull_requests: +28251
pull_request: https://github.com/python/cpython/pull/30026
___
Python tracker
<https://bugs.python.org/issue45
Change by Erlend E. Aasland :
--
pull_requests: +28248
pull_request: https://github.com/python/cpython/pull/30024
___
Python tracker
<https://bugs.python.org/issue45
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/issu
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
Erlend E. Aasland added the comment:
The _testcapi modules should stay as it is, ref. msg384272 on bpo-40077:
Yes, please keep _testcapimodule.c as it is. Static types are still
supported and need to be tested.
--
nosy: +erlendaasland
resolution: -> not a bug
st
Erlend E. Aasland added the comment:
Quoting msg407949:
> [...] We should do something like
>
> ZLIB_CFLAGS=${ZLIB_CFLAGS:-""}
> ZLIB_LIBS=${ZLIB_LIBS:-"-lz"}
>
> for all env vars.
I think we should use ${VAR-default} instead of ${VAR:-default}; we
Erlend E. Aasland added the comment:
> Imagine a person write a code with Python 3.11 and SQLite 3.8.7.2+, and then
> deploying it to Python 3.11 and SQLite 3.8.7.1-, error may occur. However,
> this situation is difficult to happen.
Yes, I also think this is a far fetched case.
Erlend E. Aasland added the comment:
> I mean, after this change, different versions of SQLite will behave
> differently.
Yes, this is explained in the news item:
Fetch across rollback no longer raises :exc:`~sqlite3.InterfaceError`.
Instead we leave it to the SQLite l
Erlend E. Aasland added the comment:
> I think this change is no problem.
Thanks, and thank you for looking reviewing this change.
> There is only one situation that a problem may occur. Write code with SQLite
> 3.8.7.2+ (2014-11-18), and run it on 3.7.15 (2012-12-12)
Erlend E. Aasland added the comment:
FWIW, it is also impossible to build the docs OOT without cluttering the source
tree.
$ cd ../build
$ make -C ../cpython.git/Doc venv
$ make -C ../cpython.git/Doc html # <= modifies Doc/build in the source
tree
--
n
Erlend E. Aasland added the comment:
I'm unable to reproduce on macOS 11.6 as well (head at
49444fb807ecb396462c8e5f547eeb5c6bc5d4de).
--
___
Python tracker
<https://bugs.python.org/issue45
Erlend E. Aasland added the comment:
Also unable to reproduce with HEAD at 8a45ca542a65ea27e7acaa44a4c833a27830e796.
Perhaps it is related to your build/dev environment?
--
___
Python tracker
<https://bugs.python.org/issue45
Erlend E. Aasland added the comment:
Also unable to reproduce with HEAD at 49444fb807ecb396462c8e5f547eeb5c6bc5d4de.
--
___
Python tracker
<https://bugs.python.org/issue45
Erlend E. Aasland added the comment:
Unable to reproduce on macOS 12 with latest 3.11 official build, and my most
recent dev build (HEAD at b394af13f69c1a2ac0e7d32dabf6d86443606ab2).
--
nosy: +erlendaasland
___
Python tracker
<ht
Change by Erlend E. Aasland :
--
pull_requests: +28075
pull_request: https://github.com/python/cpython/pull/29846
___
Python tracker
<https://bugs.python.org/issue45
New submission from Erlend E. Aasland :
SQLite 3.37.0 was released a couple of days ago:
https://sqlite.org/releaselog/3_37_0.html
Given that 3.11 feature freeze is approx. May 2022, and that it took approx. 5
months between SQLite 3.36.0 and 3.37.0, I'd say we aim for a field tested
SQLite
Change by Erlend E. Aasland :
--
versions: +Python 3.11 -Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue45
Change by Erlend E. Aasland :
--
nosy: +erlendaasland
nosy_count: 11.0 -> 12.0
pull_requests: +28065
pull_request: https://github.com/python/cpython/pull/29834
___
Python tracker
<https://bugs.python.org/issu
Erlend E. Aasland added the comment:
> Maybe this issue will be solved in issue44092
Yes, this will be resolved in bpo-44092. Hopefully I'll be able to land it
sooner than later.
--
___
Python tracker
<https://bugs.python.org/issu
101 - 200 of 828 matches
Mail list logo
