Change by E. Paine :
--
keywords: +patch
pull_requests: +22100
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23200
___
Python tracker
<https://bugs.python.org/issu
E. Paine added the comment:
This is starting to get *very* annoying. Today's failure was a new one (but
still `wait_visibility`):
test_variable_change (tkinter.test.test_ttk.test_extensions.LabeledScaleTest)
... Timeout (0:20:00)!
Thread 0x7f31dade1080 (most recent call first):
Change by E. Paine :
--
nosy: +epaine, gpolo, serhiy.storchaka
versions: +Python 3.10 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue42305>
___
___
E. Paine added the comment:
In short, the module isn't being added to the package's namespace because we
are directly modifying sys.modules (hence why the behaviour would be the same
if we imported using `import foo.b` as `from foo import b`).
I personally prefer to use the metapa
E. Paine added the comment:
Sorry Brett to readd you to the nosy for this, but we only got half a sentence
in msg380718 (which is surely not what you intended?).
While I agree with you that this is not a bug, I do feel at least a note in the
docs would be helpful to explain the implications
New submission from E. Paine :
When compiling the master branch (i.e. running 'make'), I get a
UnicodeDecodeError as follows:
Traceback (most recent call last):
File "/home/elisha/Documents/Python/cp0/cpython/./setup.py", line 2619, in
main()
File "/home/el
Change by E. Paine :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42351>
___
___
Python-bugs-list mailing list
Unsubscrib
E. Paine added the comment:
Issue 42142 covers this problem. I want to get PR-23156 merged which will
(until a better fix is found) skip tests on Ubuntu which use `wait_visibility`.
However, this is becoming more of an issue and I am worried now about the
general stability of the tkinter
E. Paine added the comment:
> Could that bot be configured to run tests with -u-gui?
This has been found to not just affect one machine: it is both Azure and Github
Ubuntu. Therefore, the only Ubuntu bot still running gui tests would be Travis.
It could be done (with a very small patch)
E. Paine added the comment:
PR 23156 [Skip select ttk tests when on Ubuntu] proposes Ubuntu-specific test
skips and is given as a justification for PR 28468 [Add
platform.freedesktop_osrelease]. However, PR 23474 [Fix timeouts in ttk tests]
attempts to correctly address the issue, though
New submission from Dave E :
I might be missing something, but I am expecting the following code to print
out a list of lists with each internal list holding one number[0-4], but
instead the internal lists are a copy of the list "count".
#!/usr/bin/python
count = range(4)
twoDim
New submission from Robert E. :
Am 16.04.2012 13:49, schrieb Python tracker:
> To complete your registration of the user "roberte" with
> Python tracker, please do one of the following:
>
> - send a reply to rep...@bugs.python.org and maintain the subject line as is
>
Robert E. added the comment:
Well I did that first but the tracker replied:
node with key "roberte" exists
Seems the username is alread in use but I still could register but not
complete the registration.
Am 16.04.2012 13:54, schrieb R. David Murray:
>
> R. David Murray a
Robert E. added the comment:
No I can't (says invalid login). I created a new account using my Google
ID which works alright. If you want to debug this problem I am happy to
help but otherwise this "bug entry" can be removed.
Cheers
Am 16.04.2012 14:47, schrieb R. David Murray
New submission from J E :
I use the turtle module to teach Python to university students. The
turtle.onkey function allows a program to register a callback function to
handle a keyboard when the turtle window has a focus. For example, this call
will result in myfun() getting called when the
e-kayrakli added the comment:
I haven't contributed to Python yet and I can contribute this as a way for me
to practice the PR process in Python.
As this is a small addition, should I create a PR right away, or wait for a
consensus here?
--
nosy: +e-kay
Change by E Kawashima :
--
keywords: +patch
pull_requests: +9649
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by E Kawashima :
--
pull_requests: +9832
___
Python tracker
<https://bugs.python.org/issue33392>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris E added the comment:
Whilst in most cases this would be correct, in this case it looks like the
original contributor took a subset of what the original author wrote and put it
into the python libraries.
Until relatively recently the ElementTree.py file included a stanza that
attempted
New submission from frank-e:
`python -m pip install --upgrade pip` on Windows 7 with Python 3.5.2 installed
for all users, PermissionError: [WinError 5] Access denied: 'c:\\program
files\\python35\\lib\\site-packages\\p
ip-8.1.1.dist-info\\description.rst'
--
components: Win
frank-e added the comment:
Thanks, worked, most likely an error on my side (command line window without
admin rights).
--
___
Python tracker
<http://bugs.python.org/issue27
New submission from E Rippey:
The "has_key" fixer in 2to3 produces wrong code on the following example:
input:"a.has_key(b)and x"
output:"b in aand x"
Note the lack of space before "and" in the input.
--
components: 2to3 (2.x to 3.x conversi
E Rippey added the comment:
I have one line change to "Lib/lib2to3/fixes/fix_has_key.py" that will resolve
this issue. Would a patch be accepted?
It doesn't seem like the input is unusually contorted.
--
status: closed -> open
New submission from E Roberts:
New to the world of Python. The picture attached is an error that a teacher at
my school is receiving when he tries to run anything in IDLE.
I know nothing about coding/python/idle or anything of that nature.
Sorry I am of little help.
Please can someone help
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
301 - 400 of 1199 matches
Mail list logo
