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
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
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: +28251
pull_request: https://github.com/python/cpython/pull/30026
___
Python tracker
<https://bugs.python.org/issue45
Change by Erlend E. Aasland :
--
pull_requests: +28254
pull_request: https://github.com/python/cpython/pull/30029
___
Python tracker
<https://bugs.python.org/issue45
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
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, 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: +erlendaa
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
Change by Erlend E. Aasland :
--
pull_requests: +28496
pull_request: https://github.com/python/cpython/pull/30280
___
Python tracker
<https://bugs.python.org/issue46
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
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:
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:
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:
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_NewR
Change by Erlend E. Aasland :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue46200>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Erlend E. Aasland :
--
pull_requests: +28570
pull_request: https://github.com/python/cpython/pull/30356
___
Python tracker
<https://bugs.python.org/issue24
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_b
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
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 bpo bot is obviously confused by the News entry path, sigh)
--
___
Python tracker
<https://bugs.python.org/issue24
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
Change by Erlend E. Aasland :
--
pull_requests: -12242
___
Python tracker
<https://bugs.python.org/issue33376>
___
___
Python-bugs-list mailing list
Unsub
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,
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
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 :
--
pull_requests: +28587
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/30377
___
Python tracker
<https://bugs.python.org/issu
Change by Erlend E. Aasland :
--
pull_requests: +28589
pull_request: https://github.com/python/cpython/pull/30379
___
Python tracker
<https://bugs.python.org/issue44
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 optio
Change by Erlend E. Aasland :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Erlend E. Aasland :
--
pull_requests: +28590
pull_request: https://github.com/python/cpython/pull/30380
___
Python tracker
<https://bugs.python.org/issue46
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: +28591
pull_request: https://github.com/python/cpython/pull/30381
___
Python tracker
<https://bugs.python.org/issue44
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 t
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 p
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.pyt
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:
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
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 c
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
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
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:
FYI: https://sqlite.org/c3ref/last_insert_rowid.html
--
___
Python tracker
<https://bugs.python.org/issue46261>
___
___
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:
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:
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[&q
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 (but not pythoninfo) I see that
>conf
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:
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
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
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:
Note, GH-30423 does _not_ fix the win_py399_crash_reproducer.py issue.
--
___
Python tracker
<https://bugs.python.org/issue46
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:
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
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/is
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:
FTR:
- in-tree build with system Python 3.8 => fails
--
___
Python tracker
<https://bugs.python.org/issue46263>
___
_
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:
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:
> 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:
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 fail
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
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:
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 :
--
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:
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 :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue45925>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 track
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
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:
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
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
Change by Erlend E. Aasland :
--
pull_requests: +28692
pull_request: https://github.com/python/cpython/pull/30489
___
Python tracker
<https://bugs.python.org/issue46
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
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
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
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:
> 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:
> 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 recon this can be closed now?
--
nosy: +erlendaasland
status: open -> pending
___
Python tracker
<https://bugs.python.org/issu
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 t
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 m
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
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:
> 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 ->
___
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.o
Erlend E. Aasland added the comment:
See also bpo-24887.
--
___
Python tracker
<https://bugs.python.org/issue46402>
___
___
Python-bugs-list mailing list
Unsub
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
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/issue46
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/issue46
Change by Erlend E. Aasland :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue46417>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issu
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/issue46
Change by Erlend E. Aasland :
--
pull_requests: +28871
pull_request: https://github.com/python/cpython/pull/30671
___
Python tracker
<https://bugs.python.org/issue46
Change by Erlend E. Aasland :
--
pull_requests: +28872
pull_request: https://github.com/python/cpython/pull/30672
___
Python tracker
<https://bugs.python.org/issue46
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 suspicio
1 - 100 of 829 matches
Mail list logo
