Erlend E. Aasland added the comment:
I'll save the cleanup till Python 3.13 dev is started. I've opened a PR for
fixing the ref leak (should be backported), and a draft PR for deprecating
Connection and Cursor reinitialisation.
--
___
Python
Change by Erlend E. Aasland :
--
pull_requests: +26654
pull_request: https://github.com/python/cpython/pull/28234
___
Python tracker
<https://bugs.python.org/issue45
Change by Erlend E. Aasland :
--
pull_requests: +26651
pull_request: https://github.com/python/cpython/pull/28231
___
Python tracker
<https://bugs.python.org/issue45
Erlend E. Aasland added the comment:
> If we deprecate but keep the buggy behavior it as it is, (1) is not needed.
> Less work for both us and the users.
Indeed.
There's still a ref leak I'd like to take care of, though: if the first audit
fails, database_obj
Erlend E. Aasland added the comment:
Great, thanks.
--
___
Python tracker
<https://bugs.python.org/issue45126>
___
___
Python-bugs-list mailing list
Unsub
Erlend E. Aasland added the comment:
FYI, I've expanded the reinit tests and added a deprecation warning to the PR.
--
___
Python tracker
<https://bugs.python.org/issue45
Erlend E. Aasland added the comment:
Modifying the loops to also print the values:
first fetch
b'0'
b'1'
second fetch
2
3
--
___
Python tracker
<https://bugs.python.org/issue45
Erlend E. Aasland added the comment:
Note: I ran that with PR 28227.
OTOH: I do agree that there's a lot of pitfalls here, especially in the future.
In the long run, it is probably best to deprecate reinit, and disable it in
Python 3.13
Erlend E. Aasland added the comment:
I modified your second example slightly:
```
import sqlite3
conn = sqlite3.connect(":memory:")
conn.text_factory=bytes
conn.row_factory = sqlite3.Row
cursor = conn.execute("CREATE TABLE foo (bar)")
numbers = range(4)
cursor.executem
Erlend E. Aasland added the comment:
> It *would* be possible to improve the documentation, though.
+1
--
___
Python tracker
<https://bugs.python.org/issu
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26648
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28227
___
Python tracker
<https://bugs.python.org/issu
Change by Erlend E. Aasland :
--
pull_requests: +26634
pull_request: https://github.com/python/cpython/pull/28209
___
Python tracker
<https://bugs.python.org/issue44
Erlend E. Aasland added the comment:
Quoting Petr from PR 28133:
Without the ability to tell SQLite to abort on trace failure, I doubt we can
do much better than the current behavior. Getting an exception and having
the data inserted seems quite irregular.
Closing this issue as won't
New submission from Erlend E. Aasland :
Quoting Petr Viktorin in PR 27940,
https://github.com/python/cpython/pull/27940#discussion_r703424148:
- db is not set to NULL if init fails.
- This segfaults for me:
import sqlite3
conn = sqlite3.connect(':memory:')
conn.execute('CREATE TABLE
Erlend E. Aasland added the comment:
In msg399939, item 2 lacks one more "reset path":
> 2. at cursor exit, if there's an active statement
Rewording this to:
2. when a statement is removed from a cursor; that is either at cursor dealloc,
or when the current statemen
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26571
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28133
___
Python tracker
<https://bugs.python.org/issu
New submission from Erlend E. Aasland :
Currently, two calls can raise exceptions in the _trace_callback() in
Modules/_sqlite/connection.c:
1. PyUnicode_DecodeUTF8() can raise an exception
2. PyObject_CallOneArg() — calling the user callback — can raise an exception
Currently, we either
Erlend E. Aasland added the comment:
>> Would it be sufficient to hold a reference to the connection object?
>
> Yes
Good, that simplifies things. I'll wait with this until we've resolved PR 27940
though.
--
___
Python tra
Change by Erlend E. Aasland :
--
pull_requests: +26531
pull_request: https://github.com/python/cpython/pull/28088
___
Python tracker
<https://bugs.python.org/issue44
Erlend E. Aasland added the comment:
> The state doesn't have a refcount, but it is owned by a module object, so
> callback_context should own a reference to the module object.
Would it be sufficient to hold a reference to the connection object? The
connection holds a ref
Erlend E. Aasland added the comment:
Thanks, good catch! I'll add that after PR 27934 is merged.
--
___
Python tracker
<https://bugs.python.org/issue42
Change by Erlend E. Aasland :
--
pull_requests: +26520
pull_request: https://github.com/python/cpython/pull/28076
___
Python tracker
<https://bugs.python.org/issue24
Change by Erlend E. Aasland :
--
pull_requests: +26518
pull_request: https://github.com/python/cpython/pull/28074
___
Python tracker
<https://bugs.python.org/issue45
Erlend E. Aasland added the comment:
Thanks, Torsten for this nice suggestion, Daniel & Aviv for the initial
patches, Gerhard & Ezio for helping improving the API, and Pablo, Asif, Hai
Shi, & Michael for reviewing and merging!
--
resolution: -> fixed
stage: patch rev
Erlend E. Aasland added the comment:
> Is something missing here?
No; all good. Thanks!
--
___
Python tracker
<https://bugs.python.org/issue43398>
___
___
Py
Change by Erlend E. Aasland :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue34561>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Erlend E. Aasland :
See also bpo-45040
Since sqlite3_finalize() will pass on any error message set by sqlite3_step(),
we can greatly simplify SQLite C API usage and error handling in
sqlite3.Cursor.executescript(), thus reducing the number of times we
save/restore thread
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26466
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28020
___
Python tracker
<https://bugs.python.org/issu
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26465
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28019
___
Python tracker
<https://bugs.python.org/issu
New submission from Erlend E. Aasland :
pysqlite_connection_commit_impl(), pysqlite_connection_rollback_impl(), and
begin_transaction() can be simplified:
sqlite3_finalize() will pass on any error set by sqlite3_step(). This implies
that we only need to check the return value
Erlend E. Aasland added the comment:
Thanks Luca, for the report, reproducer, and initial patch, Berker for helpful
suggestion, and Łukasz, Pablo, & Victor for reviewing and merging.
--
resolution: -> fixed
stage: patch review -> resolved
status: open
Change by Erlend E. Aasland :
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue45025>
___
___
Python-bugs-list mailing list
Unsubscribe:
Erlend E. Aasland added the comment:
Neat! Thanks :)
--
___
Python tracker
<https://bugs.python.org/issue44972>
___
___
Python-bugs-list mailing list
Unsub
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26427
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/27979
___
Python tracker
<https://bugs.python.org/issu
Erlend E. Aasland added the comment:
Thanks, Ronald, that's a nice improvement. I'll create a PR for it.
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Erlend E. Aasland :
--
resolution: fixed ->
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue44997>
___
___
Python-bugs-
Erlend E. Aasland added the comment:
Er, a little bit too fast there. There is still a crash, but it is of course
postponed bco. bpo-44976. New reproducer:
import sqlite3 as sqlite
con = sqlite.connect(':memory:', detect_types=sqlite.PARSE_COLNAMES)
cur = con.cursor()
sqlite.converters
Erlend E. Aasland added the comment:
After GH-27884 (bpo-44976) there is no longer a segfault.
I suggest to expand the test suite with the reproducer Sergey provided.
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Erlend E. Aasland :
--
status: pending -> open
Removed message: https://bugs.python.org/msg400334
___
Python tracker
<https://bugs.python.org/issu
Erlend E. Aasland added the comment:
This issue was fixed by GH-27884 (bpo-44976). I suggest to expand the test
suite with the reproducer Sergey provided before closing the issue.
--
status: open -> pending
___
Python tracker
<
Change by Erlend E. Aasland :
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue43398>
___
___
Python-bugs-list mailing list
Un
Change by Erlend E. Aasland :
--
pull_requests: +26413
status: pending -> open
pull_request: https://github.com/python/cpython/pull/27966
___
Python tracker
<https://bugs.python.org/issu
Erlend E. Aasland added the comment:
This issue has been fixed by recent sqlite3 improvements. Suggesting to still
expand the test suite with tests for defect connection factories.
--
status: open -> pending
___
Python tracker
<
Erlend E. Aasland added the comment:
...or we can just leave it as it. Seems like these reports only pops up once in
a while.
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Erlend E. Aasland :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue45007>
___
___
Python-bugs-list mailing list
Unsubscribe:
Erlend E. Aasland added the comment:
Thanks for merging the NEWS amendments, Pablo. We can close this issue after
landing PR 27642.
--
___
Python tracker
<https://bugs.python.org/issue43
Erlend E. Aasland added the comment:
> FTR, this is only a problem if you link with the Apple-supplied system
> libsqlite3 [...]
Sure, but that should be relatively trivial to detect. AFAIK, the SQLite
command line shell seems to be located at the same path every release, so I
would
Change by Erlend E. Aasland :
--
pull_requests: +26400
pull_request: https://github.com/python/cpython/pull/27953
___
Python tracker
<https://bugs.python.org/issue43
Change by Erlend E. Aasland :
--
pull_requests: +26399
pull_request: https://github.com/python/cpython/pull/27952
___
Python tracker
<https://bugs.python.org/issue43
Erlend E. Aasland added the comment:
We'll do the changes Petr proposed first, and then I'll see how invasive the
other changes will be. If the diffs end up being concise, I'll put them up for
review :)
--
___
Python tracker
<ht
Erlend E. Aasland added the comment:
IIRC, macOS deprecated this functionality some releases ago. Seems like they've
now removed it completely.
I guess we could wrap this functionality with some preprocessor conditionals,
and/or adjust the configure script to not accept
--enable-loadable
Change by Erlend E. Aasland :
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue44997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Erlend E. Aasland :
--
title: _sqlite3 extention failed to build -> [sqlite3] build fails on macOS
11.5.1
___
Python tracker
<https://bugs.python.org/issu
Change by Erlend E. Aasland :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue44997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Erlend E. Aasland :
--
pull_requests: +26390
pull_request: https://github.com/python/cpython/pull/27944
___
Python tracker
<https://bugs.python.org/issue27
Change by Erlend E. Aasland :
--
pull_requests: +26389
pull_request: https://github.com/python/cpython/pull/27943
___
Python tracker
<https://bugs.python.org/issue27
Change by Erlend E. Aasland :
--
pull_requests: +26388
pull_request: https://github.com/python/cpython/pull/27942
___
Python tracker
<https://bugs.python.org/issue27
Change by Erlend E. Aasland :
--
pull_requests: +26385
pull_request: https://github.com/python/cpython/pull/27940
___
Python tracker
<https://bugs.python.org/issue42
Erlend E. Aasland added the comment:
I'd like to propose further enhancements:
- use intermingled declarations in the affected functions; this will make GIL
acquisition stand more out, and it also improves readability and makes it
easier to trace refs
- take the naming step further: I'd
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26383
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27934
___
Python tracker
<https://bugs.python.org/issu
Erlend E. Aasland added the comment:
Petr:
> I think the module could use a more comprehensive review for GIL handling
> [...]
I agree. I created bpo-44991 for this.
--
___
Python tracker
<https://bugs.python.org/i
New submission from Erlend E. Aasland :
Quoting msg400205 by Petr in bpo-42064:
I think the module could use a more comprehensive review for GIL handling,
rather than doing it piecewise in individual PRs. I recommend that any function
passed to SQLite (and only those) should
- be named
Erlend E. Aasland added the comment:
> What about new tests and NEWS update?
See PR 27642 for the expanded tests, and PR 27922 for amending news entries. I
didn't combine the two, as I figured you might have more comments on the former
Change by Erlend E. Aasland :
--
Removed message: https://bugs.python.org/msg399133
___
Python tracker
<https://bugs.python.org/issue43853>
___
___
Python-bug
Change by Erlend E. Aasland :
--
pull_requests: +26374
pull_request: https://github.com/python/cpython/pull/27922
___
Python tracker
<https://bugs.python.org/issue43
Erlend E. Aasland added the comment:
> first-time contributors need a maintainer to approve the workflows for their
> PRs
How is manually dispatched workflows different from just opening a PR to your
own fork? I do that from time to time in order to run the CI before opening a
PR a
Erlend E. Aasland added the comment:
Historical note:
The current behaviour was introduced in pysqlite v2.0.2 (May 21 2005), in order
to be able to finalise statements and thus close cursors as soon as possible.
However, that effect was cancelled just after a couple of months
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26339
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27884
___
Python tracker
<https://bugs.python.org/issu
New submission from Erlend E. Aasland :
Currently, we build the first result row in the _pysqlite_query_execute() loop
if sqlite3_step() returned SQLITE_ROW. When the user asks for a row (for
example, using sqlite3.Cursor.fetchone()), this pre-built row is returned, and
the next row
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26320
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27865
___
Python tracker
<https://bugs.python.org/issu
New submission from Erlend E. Aasland :
Currently, if a non-DML statement is executed with executemany(), we only bail
as late as possible: just before the call to _pysqlite_fetch_one_row(). This
means that we've already stepped through the statement once (!), and possibly
bound values
Erlend E. Aasland added the comment:
I did a quick count of sqlite3_reset()s in the sqlite3 test suite:
- main: 2976 calls
- PR 27844: 1730 calls
Since we never call sqlite3_reset() with a NULL pointer, all sqlite3_reset()
calls we execute hold the SQLite db mutex; reducing the number
Change by Erlend E. Aasland :
--
Removed message: https://bugs.python.org/msg399931
___
Python tracker
<https://bugs.python.org/issue44958>
___
___
Python-bug
Erlend E. Aasland added the comment:
Ref. Serhiy's msg387858 in bpo-43350:
"Maybe the code could be rewritten in more explicit way and call
pysqlite_statement_reset() only when it is necessary [...]"
Currently, we try to reset statements in all "statement exit" ro
Erlend E. Aasland added the comment:
msg387858 (Serhiy):
> Maybe the code could be rewritten in more explicit way and call
> pysqlite_statement_reset() only when it is necessary [...]
I've opened bpo-44958 for such an enhancement. Closing this issue.
--
resolution: ->
Erlend E. Aasland added the comment:
See also bpo-44958
--
___
Python tracker
<https://bugs.python.org/issue44073>
___
___
Python-bugs-list mailing list
Unsub
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26307
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27844
___
Python tracker
<https://bugs.python.org/issu
New submission from Erlend E. Aasland :
Ref. Serhiy's msg387858 in bpo-43350:
"Maybe the code could be rewritten in more explicit way and call
pysqlite_statement_reset() only when it is necessary [...]"
Currently, we try to reset statements in all "statement exit" ro
Erlend E. Aasland added the comment:
Thanks Pablo for merging, and Berker for pushing me to investigate further.
Highly appreciated!
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Erlend E. Aasland :
--
title: [sqlite3] insert -> [sqlite3] proposal: add sqlite3.Cursor.insert()
method
___
Python tracker
<https://bugs.python.org/issu
Erlend E. Aasland added the comment:
The INSERT statement comes in many varieties. What about INSERT OR
[ABORT,FAIL,IGNORE,REPLACE,ROLLBACK], INSERT WITH RECURSIVE, INSERT INTO table
SELECT, etc.? Why only add such an API for insert; why not replace() as well?
I'm not convinced
Change by Erlend E. Aasland :
--
pull_requests: +26255
pull_request: https://github.com/python/cpython/pull/27786
___
Python tracker
<https://bugs.python.org/issue16
Erlend E. Aasland added the comment:
>> What would it take to get this merged?
>
> I've rebased Aviv's PR (GH-1108) onto main and resolved the conflicts.
> If I get his blessing, I'll open a PR try to land this.
I asked Aviv on GH eight days ago, and I haven't heard anyth
Change by Erlend E. Aasland :
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue44927>
___
___
Python-bugs-list mailing list
Unsubscribe:
Erlend E. Aasland added the comment:
Berker:
> My understanding is that their usages is a bit different:
> one is for performance reasons (and it can configurable by users) and the
> other is to keep track of statements inside a connection.
>
> I'm not fully sure that the bot
Erlend E. Aasland added the comment:
I've been fiddling with this between others projects lately; the PR is mostly
ready. The only remaining issue is how to include this in the Connection object:
- The serialize API was added as a compile-time option
(SQLITE_ENABLE_DESERIALIZE) in SQLite
Erlend E. Aasland added the comment:
> Also, for SQLite 3.7.17 and above, we should raise sqlite3.Warning for error
> codes SQLITE_NOTICE and SQLITE_WARNING.
Er, forget that. Neither are returned by any SQLite C interface, at the moment.
They can (currently) only be used as the
Erlend E. Aasland added the comment:
See also bpo-35398
--
___
Python tracker
<https://bugs.python.org/issue36859>
___
___
Python-bugs-list mailing list
Unsub
Erlend E. Aasland added the comment:
See also bpo-36859.
--
nosy: +erlendaasland
___
Python tracker
<https://bugs.python.org/issue35398>
___
___
Python-bug
Erlend E. Aasland added the comment:
This was fixed in bpo-42686. Closing as duplicate.
--
nosy: +erlendaasland
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> include built-in Math functions in SQLite to 3.35.0 of
Change by Erlend E. Aasland :
--
pull_requests: +26181
pull_request: https://github.com/python/cpython/pull/27695
___
Python tracker
<https://bugs.python.org/issue44
Erlend E. Aasland added the comment:
Also, for SQLite 3.7.17 and above, we should raise sqlite3.Warning for error
codes SQLITE_NOTICE and SQLITE_WARNING.
--
___
Python tracker
<https://bugs.python.org/issue44
Erlend E. Aasland added the comment:
* sqlite3.ProgrammingError is raised for SQLITE_MISUSE. IMO,
sqlite3.InterfaceError, is more appropriate.
* In case of too large integer values, OverflowError is raised on bind, but
sqlite3.DataError is raised on UDF return. Using sqlite3.DataError
Erlend E. Aasland added the comment:
> What would it take to get this merged?
I've rebased Aviv's PR (GH-1108) onto main and resolved the conflicts. If I get
his blessing, I'll open a PR try to land this.
--
___
Python tracker
<
Erlend E. Aasland added the comment:
Thanks, Serhiy!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Erlend E. Aasland :
--
nosy: -erlendaasland
___
Python tracker
<https://bugs.python.org/issue41576>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Erlend E. Aasland :
--
title: [doc] some sqlite3 exceptions are not documented -> [doc] Complete the
sqlite3 exception documentation
___
Python tracker
<https://bugs.python.org/issu
Erlend E. Aasland added the comment:
Also, the documentation of sqlite3.Warning could be improved. Currently, it
reads "A subclass of Exception".
Suggesting to simply sync the descriptions of the exceptions with PEP 249.
--
___
Pyth
Change by Erlend E. Aasland :
--
title: [DOC] some sqlite3 exceptions are not documented -> [doc] some sqlite3
exceptions are not documented
___
Python tracker
<https://bugs.python.org/issu
Change by Erlend E. Aasland :
--
keywords: +patch
pull_requests: +26139
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27645
___
Python tracker
<https://bugs.python.org/issu
401 - 500 of 828 matches
Mail list logo
