[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
New submission from Ned Batchelder :
Under tox, sys._base_executable is not an actual file for 3.11.0a3. It was
fine in 3.11.0a2.
To reproduce:
--- 8<
# tox.ini
[tox]
envlist = py{310,311a2,311}
skipsdist = True
[testenv]
commands =
python -c "import sys,os.path; print(e := sys._base_executable);
print(os.path.exists(e))"
[testenv:py311a2]
# This is the path to 3.11.0a2 if you have it.
basepython = /usr/local/pyenv/pyenv/versions/3.11.0a2/bin/python3
Create a new Python 3.8 virtualenv, and install latest tox (3.24.4 for me).
Then run "tox". I see:
py310 create: /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py310
py310 run-test-pre: PYTHONHASHSEED='534434199'
py310 run-test: commands[0] | python -c 'import sys,os.path; print(e :=
sys._base_executable); print(os.path.exists(e))'
/Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py310/bin/python
True
py311a2 create: /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py311a2
py311a2 run-test-pre: PYTHONHASHSEED='534434199'
py311a2 run-test: commands[0] | python -c 'import sys,os.path; print(e :=
sys._base_executable); print(os.path.exists(e))'
/Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py311a2/bin/python
True
py311 create: /Users/nedbatchelder/coverage/lab/fix-3.11a3/.tox/py311
py311 run-test-pre: PYTHONHASHSEED='534434199'
py311 run-test: commands[0] | python -c 'import sys,os.path; print(e :=
sys._base_executable); print(os.path.exists(e))'
/usr/local/pyenv/pyenv/versions/3.11.0a3/python
False
_ summary
_
py310: commands succeeded
py311a2: commands succeeded
py311: commands succeeded
congratulations :)
This came to my attention because the coverage.py test suite uses "python -m
venv" to create environments. They worked under 3.11.0a2, but failed under a3.
I tracked it down to a difference in sys._base_executable.
I couldn't see a difference in those values without tox, but I'm not sure why
it changes the results.
--
keywords: 3.11regression
messages: 408166
nosy: nedbat, pablogsal
priority: normal
severity: normal
status: open
title: 3.11.0a3: under tox, sys._base_executable is wrong
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46028>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Ned Batchelder added the comment: git bisect also identifies that commit as the first bad: 99fcf1505218464c489d419d4500f126b6d6dc28 is the first bad commit commit 99fcf1505218464c489d419d4500f126b6d6dc28 Author: Steve Dower Date: Fri Dec 3 00:08:42 2021 + bpo-45582: Port getpath[p].c to Python (GH-29041) The getpath.py file is frozen at build time and executed as code over a namespace. It is never imported, nor is it meant to be importable or reusable. However, it should be easier to read, modify, and patch than the previous code. This commit attempts to preserve every previously tested quirk, but these may be changed in the future to better align platforms. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Ned Batchelder added the comment: Tox isn't needed, just venv from the stdlib: $ python3.11.0a2 -m venv venv_a2 $ venv_a2/bin/python -c "import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))" /private/tmp/venv_a2/bin/python True $ python3.11.0a3 -m venv venv_a3 $ venv_a3/bin/python -c "import sys,os.path; print(e := sys._base_executable); print(os.path.exists(e))" /usr/local/bin/python False -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Ned Batchelder added the comment: The two venvs seem analogous: $ cat venv_a2/pyvenv.cfg home = /usr/local/bin include-system-site-packages = false version = 3.11.0 $ ls -al venv_a2/bin total 72 drwxr-xr-x 13 nedbatchelder wheel 416 Dec 11 10:43 ./ drwxr-xr-x 6 nedbatchelder wheel 192 Dec 11 10:43 ../ -rw-r--r-- 1 nedbatchelder wheel 9033 Dec 11 10:43 Activate.ps1 -rw-r--r-- 1 nedbatchelder wheel 1993 Dec 11 10:43 activate -rw-r--r-- 1 nedbatchelder wheel 919 Dec 11 10:43 activate.csh -rw-r--r-- 1 nedbatchelder wheel 2061 Dec 11 10:43 activate.fish -rwxr-xr-x 1 nedbatchelder wheel 244 Dec 11 10:43 pip* -rwxr-xr-x 1 nedbatchelder wheel 244 Dec 11 10:43 pip3* -rwxr-xr-x 1 nedbatchelder wheel 244 Dec 11 10:43 pip3.11* lrwxr-xr-x 1 nedbatchelder wheel14 Dec 11 10:43 python@ -> python3.11.0a2 lrwxr-xr-x 1 nedbatchelder wheel14 Dec 11 10:43 python3@ -> python3.11.0a2 lrwxr-xr-x 1 nedbatchelder wheel14 Dec 11 10:43 python3.11@ -> python3.11.0a2 lrwxr-xr-x 1 nedbatchelder wheel29 Dec 11 10:43 python3.11.0a2@ -> /usr/local/bin/python3.11.0a2 $ cat venv_a3/pyvenv.cfg home = /usr/local/bin include-system-site-packages = false version = 3.11.0 $ ls -al venv_a3/bin total 72 drwxr-xr-x 13 nedbatchelder wheel 416 Dec 11 10:43 ./ drwxr-xr-x 6 nedbatchelder wheel 192 Dec 11 10:43 ../ -rw-r--r-- 1 nedbatchelder wheel 9033 Dec 11 10:43 Activate.ps1 -rw-r--r-- 1 nedbatchelder wheel 1993 Dec 11 10:43 activate -rw-r--r-- 1 nedbatchelder wheel 919 Dec 11 10:43 activate.csh -rw-r--r-- 1 nedbatchelder wheel 2061 Dec 11 10:43 activate.fish -rwxr-xr-x 1 nedbatchelder wheel 244 Dec 11 10:43 pip* -rwxr-xr-x 1 nedbatchelder wheel 244 Dec 11 10:43 pip3* -rwxr-xr-x 1 nedbatchelder wheel 244 Dec 11 10:43 pip3.11* lrwxr-xr-x 1 nedbatchelder wheel14 Dec 11 10:43 python@ -> python3.11.0a3 lrwxr-xr-x 1 nedbatchelder wheel14 Dec 11 10:43 python3@ -> python3.11.0a3 lrwxr-xr-x 1 nedbatchelder wheel14 Dec 11 10:43 python3.11@ -> python3.11.0a3 lrwxr-xr-x 1 nedbatchelder wheel29 Dec 11 10:43 python3.11.0a3@ -> /usr/local/bin/python3.11.0a3 -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Ned Batchelder added the comment: This started because a set of tests in the coverage.py test suite fail with 3.11.0a3. They attempt to create a venv in the test, and the test is already running inside a virtualenv. The venv creation fails, with a reference to a non-existent file. I wrote the bug about sys._base_executable because that seemed to be the central difference that was causing the problem. I was not relying on sys._base_executable, venv was. I will find steps to reproduce that don't reference sys._base_executable if you need them. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Ned Batchelder added the comment: Demonstration of a problem with only stdlib, and no undocumented features. This is on a Mac: This works: $ python3.10 -V Python 3.10.0 $ python3.10 -m venv v310 $ v310/bin/python -m venv v310-nested $ v310-nested/bin/python -V Python 3.10.0 This does not work: $ python3.11 -V Python 3.11.0a3 $ python3.11 -m venv v311 $ v311/bin/python -m venv 311-nested Error: [Errno 2] No such file or directory: '/private/tmp/bpo-46028/311-nested/bin/python' -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Ned Batchelder added the comment: > I assume /private/tmp/bpo-46028/311-nested/bin/python3.11 exists though? Yes, that file exists, but it's a symlink to a non-existent file: $ ls -al 311-nested/bin total 0 drwxr-xr-x 5 nedbatchelder wheel 160 Dec 13 18:04 ./ drwxr-xr-x 6 nedbatchelder wheel 192 Dec 13 18:04 ../ lrwxr-xr-x 1 nedbatchelder wheel 21 Dec 13 18:04 python@ -> /usr/local/bin/python lrwxr-xr-x 1 nedbatchelder wheel6 Dec 13 18:04 python3@ -> python lrwxr-xr-x 1 nedbatchelder wheel6 Dec 13 18:04 python3.11@ -> python $ ls -al /usr/local/bin/python ls: /usr/local/bin/python: No such file or directory -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Ned Batchelder added the comment: Here's the experiment again with 3.10.1 and 3.11.0a3, and more ls's: $ python3.10 -V Python 3.10.1 $ python3.10 -m venv v310 $ ls -al v310/bin total 72 drwxr-xr-x 12 nedbatchelder wheel 384 Dec 16 06:42 ./ drwxr-xr-x 6 nedbatchelder wheel 192 Dec 16 06:42 ../ -rw-r--r-- 1 nedbatchelder wheel 9033 Dec 16 06:42 Activate.ps1 -rw-r--r-- 1 nedbatchelder wheel 1993 Dec 16 06:42 activate -rw-r--r-- 1 nedbatchelder wheel 919 Dec 16 06:42 activate.csh -rw-r--r-- 1 nedbatchelder wheel 2061 Dec 16 06:42 activate.fish -rwxr-xr-x 1 nedbatchelder wheel 246 Dec 16 06:42 pip* -rwxr-xr-x 1 nedbatchelder wheel 246 Dec 16 06:42 pip3* -rwxr-xr-x 1 nedbatchelder wheel 246 Dec 16 06:42 pip3.10* lrwxr-xr-x 1 nedbatchelder wheel10 Dec 16 06:42 python@ -> python3.10 lrwxr-xr-x 1 nedbatchelder wheel10 Dec 16 06:42 python3@ -> python3.10 lrwxr-xr-x 1 nedbatchelder wheel25 Dec 16 06:42 python3.10@ -> /usr/local/bin/python3.10 $ ls -al /usr/local/bin/python3.10 lrwxr-xr-x 1 nedbatchelder admin 53 Dec 16 06:38 /usr/local/bin/python3.10@ -> /usr/local/pyenv/pyenv/versions/3.10.1/bin/python3.10 $ v310/bin/python -m venv v310-nested $ v310-nested/bin/python -V Python 3.10.1 $ ls -al v310-nested/bin total 72 drwxr-xr-x 12 nedbatchelder wheel 384 Dec 16 06:43 ./ drwxr-xr-x 6 nedbatchelder wheel 192 Dec 16 06:43 ../ -rw-r--r-- 1 nedbatchelder wheel 9033 Dec 16 06:43 Activate.ps1 -rw-r--r-- 1 nedbatchelder wheel 2014 Dec 16 06:43 activate -rw-r--r-- 1 nedbatchelder wheel 940 Dec 16 06:43 activate.csh -rw-r--r-- 1 nedbatchelder wheel 2082 Dec 16 06:43 activate.fish -rwxr-xr-x 1 nedbatchelder wheel 249 Dec 16 06:43 pip* -rwxr-xr-x 1 nedbatchelder wheel 249 Dec 16 06:43 pip3* -rwxr-xr-x 1 nedbatchelder wheel 249 Dec 16 06:43 pip3.10* lrwxr-xr-x 1 nedbatchelder wheel37 Dec 16 06:43 python@ -> /private/tmp/bpo46028/v310/bin/python lrwxr-xr-x 1 nedbatchelder wheel 6 Dec 16 06:43 python3@ -> python lrwxr-xr-x 1 nedbatchelder wheel 6 Dec 16 06:43 python3.10@ -> python $ ls -al /private/tmp/bpo46028/v310/bin/python lrwxr-xr-x 1 nedbatchelder wheel 10 Dec 16 06:42 /private/tmp/bpo46028/v310/bin/python@ -> python3.10 $ python3.11 -V Python 3.11.0a3 $ python3.11 -m venv v311 $ ls -al v311/bin total 72 drwxr-xr-x 12 nedbatchelder wheel 384 Dec 16 06:45 ./ drwxr-xr-x 6 nedbatchelder wheel 192 Dec 16 06:45 ../ -rw-r--r-- 1 nedbatchelder wheel 9033 Dec 16 06:45 Activate.ps1 -rw-r--r-- 1 nedbatchelder wheel 1993 Dec 16 06:45 activate -rw-r--r-- 1 nedbatchelder wheel 919 Dec 16 06:45 activate.csh -rw-r--r-- 1 nedbatchelder wheel 2061 Dec 16 06:45 activate.fish -rwxr-xr-x 1 nedbatchelder wheel 246 Dec 16 06:45 pip* -rwxr-xr-x 1 nedbatchelder wheel 246 Dec 16 06:45 pip3* -rwxr-xr-x 1 nedbatchelder wheel 246 Dec 16 06:45 pip3.11* lrwxr-xr-x 1 nedbatchelder wheel10 Dec 16 06:45 python@ -> python3.11 lrwxr-xr-x 1 nedbatchelder wheel10 Dec 16 06:45 python3@ -> python3.11 lrwxr-xr-x 1 nedbatchelder wheel25 Dec 16 06:45 python3.11@ -> /usr/local/bin/python3.11 $ ls -al /usr/local/bin/python3.11 lrwxr-xr-x 1 nedbatchelder admin 55 Dec 9 12:23 /usr/local/bin/python3.11@ -> /usr/local/pyenv/pyenv/versions/3.11.0a3/bin/python3.11 $ v311/bin/python -m venv v311-nested Error: [Errno 2] No such file or directory: '/private/tmp/bpo46028/v311-nested/bin/python' $ ls -al v311-nested/bin total 0 drwxr-xr-x 5 nedbatchelder wheel 160 Dec 16 06:45 ./ drwxr-xr-x 6 nedbatchelder wheel 192 Dec 16 06:45 ../ lrwxr-xr-x 1 nedbatchelder wheel 21 Dec 16 06:45 python@ -> /usr/local/bin/python lrwxr-xr-x 1 nedbatchelder wheel6 Dec 16 06:45 python3@ -> python lrwxr-xr-x 1 nedbatchelder wheel6 Dec 16 06:45 python3.11@ -> python $ ls -al /usr/local/bin/python ls: /usr/local/bin/python: No such file or directory -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Ned Batchelder added the comment: Thanks, your change looks good. The exact symlinks in the nested venv's are different for 3.10.1 and your 3.11, but they both work: $ python3.10 -c "import sys; print(sys.version)" 3.10.1 (main, Dec 14 2021, 08:30:13) [Clang 12.0.0 (clang-1200.0.32.29)] $ python3.10 -m venv v310 $ ls -al v310/bin/py* lrwxr-xr-x 1 nedbatchelder wheel 10 Dec 16 18:48 v310/bin/python@ -> python3.10 lrwxr-xr-x 1 nedbatchelder wheel 10 Dec 16 18:48 v310/bin/python3@ -> python3.10 lrwxr-xr-x 1 nedbatchelder wheel 25 Dec 16 18:48 v310/bin/python3.10@ -> /usr/local/bin/python3.10 $ v310/bin/python -m venv v310-nested $ ls -al v310-nested/bin/py* lrwxr-xr-x 1 nedbatchelder wheel 37 Dec 16 18:48 v310-nested/bin/python@ -> /private/tmp/bpo46028/v310/bin/python lrwxr-xr-x 1 nedbatchelder wheel 6 Dec 16 18:48 v310-nested/bin/python3@ -> python lrwxr-xr-x 1 nedbatchelder wheel 6 Dec 16 18:48 v310-nested/bin/python3.10@ -> python $ $ python3.11 -c "import sys; print(sys.version)" 3.11.0a3+ (heads/pr/30144:8b260a8606, Dec 16 2021, 14:31:40) [Clang 12.0.0 (clang-1200.0.32.29)] $ python3.11 -m venv v311 $ ls -al v311/bin/py* lrwxr-xr-x 1 nedbatchelder wheel 10 Dec 16 18:50 v311/bin/python@ -> python3.11 lrwxr-xr-x 1 nedbatchelder wheel 10 Dec 16 18:50 v311/bin/python3@ -> python3.11 lrwxr-xr-x 1 nedbatchelder wheel 25 Dec 16 18:50 v311/bin/python3.11@ -> /usr/local/bin/python3.11 $ v311/bin/python -m venv v311-nested $ ls -al v311-nested/bin/py* lrwxr-xr-x 1 nedbatchelder wheel 10 Dec 16 18:50 v311-nested/bin/python@ -> python3.11 lrwxr-xr-x 1 nedbatchelder wheel 10 Dec 16 18:50 v311-nested/bin/python3@ -> python3.11 lrwxr-xr-x 1 nedbatchelder wheel 33 Dec 16 18:50 v311-nested/bin/python3.11@ -> /usr/local/cpython/bin/python3.11 -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46225] f_lasti behaves differently for lambdas returned from loops
New submission from Ned Batchelder :
Python 3.11.0a3 changed how f_lasti behaves when calling a function in some
situations.
This example shows returning a lambda from a function. If the lambda is
returned in a loop, then frame.f_lasti is 0 when it is called. If the lambda
is not in a loop, then f_lasti is -1, as is usual when calling a function.
This behavior first appeared in 3.11.0a3.
---< showit.py >--
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
if event != "line":
lineno = frame.f_lineno
lasti = f"lasti {frame.f_lasti}" if event == "call" else ""
line = linecache.getline(__file__, lineno).rstrip()
print("{} {} {:10}: {}".format(event[:4], lineno, lasti, line))
return trace
print(sys.version)
sys.settrace(trace)
def run1():
for i in range(1):
return lambda: i
def run2():
return lambda: 99
f = run1()
print(f())
f = run2()
print(f())
--
Here are 3.10, 3.11.0a2, 3.11.0a3, and the tip of 3.11. The changing line is
marked with <<<<<:
$ python3.10 showit.py
3.10.1 (main, Dec 14 2021, 08:30:13) [Clang 12.0.0 (clang-1200.0.32.29)]
call 16 lasti -1 : def run1():
retu 18 : return lambda: i
call 18 lasti -1 : return lambda: i<<<<<
retu 18 : return lambda: i
0
call 20 lasti -1 : def run2():
retu 21 : return lambda: 99
call 21 lasti -1 : return lambda: 99
retu 21 : return lambda: 99
99
$ /usr/local/pyenv/pyenv/versions/3.11.0a2/bin/python3.11 showit.py
3.11.0a2 (main, Nov 6 2021, 07:16:30) [Clang 12.0.0 (clang-1200.0.32.29)]
call 16 lasti -1 : def run1():
retu 18 : return lambda: i
call 18 lasti -1 : return lambda: i<<<<<
retu 18 : return lambda: i
0
call 20 lasti -1 : def run2():
retu 21 : return lambda: 99
call 21 lasti -1 : return lambda: 99
retu 21 : return lambda: 99
99
$ /usr/local/pyenv/pyenv/versions/3.11.0a3/bin/python3.11 showit.py
3.11.0a3 (main, Dec 9 2021, 12:22:18) [Clang 12.0.0 (clang-1200.0.32.29)]
call 16 lasti -1 : def run1():
retu 18 : return lambda: i
call 18 lasti 0 : return lambda: i<<<<<
retu 18 : return lambda: i
0
call 20 lasti -1 : def run2():
retu 21 : return lambda: 99
call 21 lasti -1 : return lambda: 99
retu 21 : return lambda: 99
99
$ /usr/local/cpython/bin/python3 showit.py
3.11.0a3+ (heads/main:a82baed0e9, Jan 2 2022, 08:12:01) [Clang 12.0.0
(clang-1200.0.32.29)]
call 16 lasti -1 : def run1():
retu 18 : return lambda: i
call 18 lasti 0 : return lambda: i<<<<<
retu 18 : return lambda: i
0
call 20 lasti -1 : def run2():
retu 21 : return lambda: 99
call 21 lasti -1 : return lambda: 99
retu 21 : return lambda: 99
99
--
keywords: 3.11regression
messages: 409496
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: f_lasti behaves differently for lambdas returned from loops
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46225>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46225] f_lasti behaves differently for lambdas returned from loops
Ned Batchelder added the comment: Also, this only happens with a Python trace function. With a C trace function, pPyFrameObject->f_frame->f_lasti is -1. -- ___ Python tracker <https://bugs.python.org/issue46225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46234] 3.11: Tracing of decorators now visits the decorator line before the decorator function
New submission from Ned Batchelder :
Sometime after 3.11.0a3, tracing of decorators changed so that each decorator
line is revisited as the decorator is invoked. Is this intentional?
---< dectrace.py >---
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
print(sys.version)
sys.settrace(trace)
def decorator(func):
return func
def doit():
@decorator
@decorator
@decorator
def func(x):
return x + 1
print(func(1))
doit()
-
Running it on 3.10, 3.11.0a3, and latest 3.11. The last run has the new line
hightlighted with <<<<<:
$ python3.10 dectrace.py
3.10.1 (main, Dec 14 2021, 08:30:13) [Clang 12.0.0 (clang-1200.0.32.29)]
call 16: def doit():
line 17: @decorator
line 18: @decorator
line 19: @decorator
line 20: def func(x):
call 13: def decorator(func):
line 14: return func
retu 14: return func
call 13: def decorator(func):
line 14: return func
retu 14: return func
call 13: def decorator(func):
line 14: return func
retu 14: return func
line 23: print(func(1))
call 17: @decorator
line 21: return x + 1
retu 21: return x + 1
2
retu 23: print(func(1))
$ python3.11 dectrace.py
3.11.0a3 (main, Dec 9 2021, 12:22:18) [Clang 12.0.0 (clang-1200.0.32.29)]
call 16: def doit():
line 17: @decorator
line 18: @decorator
line 19: @decorator
line 20: def func(x):
call 13: def decorator(func):
line 14: return func
retu 14: return func
call 13: def decorator(func):
line 14: return func
retu 14: return func
call 13: def decorator(func):
line 14: return func
retu 14: return func
line 23: print(func(1))
call 17: @decorator
line 21: return x + 1
retu 21: return x + 1
2
retu 23: print(func(1))
$ /usr/local/cpython/bin/python3.11 dectrace.py
3.11.0a3+ (heads/main:a82baed0e9, Jan 2 2022, 08:12:01) [Clang 12.0.0
(clang-1200.0.32.29)]
call 16: def doit():
line 17: @decorator
line 18: @decorator
line 19: @decorator
line 20: def func(x):
line 19: @decorator <<<<<
call 13: def decorator(func):
line 14: return func
retu 14: return func
line 18: @decorator <<<<<
call 13: def decorator(func):
line 14: return func
retu 14: return func
line 17: @decorator <<<<<
call 13: def decorator(func):
line 14: return func
retu 14: return func
line 20: def func(x):
line 23: print(func(1))
call 17: @decorator
line 21: return x + 1
retu 21: return x + 1
2
retu 23: print(func(1))
(this might or might not be related to https://bugs.python.org/issue37971)
--
components: Interpreter Core
keywords: 3.11regression
messages: 409539
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: 3.11: Tracing of decorators now visits the decorator line before the
decorator function
type: behavior
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46234>
___
___
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
New submission from Ned Batchelder :
This code seems to get a RESUME opcode where no function call is happening:
a = 1
fn = lambda 2
b = 3
Here is the disassembly. Offset 6 has a RESUME opcode for line 2:
Python 3.11.0a3+ (heads/main:0fc58c1e05, Jan 8 2022, 19:45:58) [Clang 12.0.0
(clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> dis.dis("""\
... a = 1
... fn = lambda: 2
... b = 3
... """)
0 RESUME 0
1 2 LOAD_CONST 0 (1)
4 STORE_NAME 0 (a)
2 6 RESUME 0
8 LOAD_CONST 1 ( at
0x10772c2d0, file "", line 2>)
10 MAKE_FUNCTION0
12 STORE_NAME 1 (fn)
3 14 LOAD_CONST 2 (3)
16 STORE_NAME 2 (b)
18 LOAD_CONST 3 (None)
20 RETURN_VALUE
Disassembly of at 0x10772c2d0, file "", line 2>:
2 0 RESUME 0
2 LOAD_CONST 1 (2)
4 RETURN_VALUE
This causes an extra "call" event when tracing:
---< bug233.py >
import linecache, os.path, sys
def trace(frame, event, arg):
if (event != "line") and ("bug233" in frame.f_code.co_filename):
lineno = frame.f_lineno
first = frame.f_code.co_firstlineno
source = linecache.getline(frame.f_code.co_filename, lineno) if lineno
else "**"
file = os.path.basename(frame.f_code.co_filename)
print("{} {}@{!s:4} (first={}): {}".format(event[:4], file, lineno,
first, source.rstrip()))
return trace
print(sys.version)
sys.settrace(trace)
def f():
a = 1
fn = lambda: 2
b = 3
f()
% python3.10 bug233.py
3.10.1 (main, Dec 14 2021, 08:30:13) [Clang 12.0.0 (clang-1200.0.32.29)]
call bug233.py@15 (first=15): def f():
retu bug233.py@18 (first=15): b = 3
% python3.11 bug233.py
3.11.0a3+ (heads/main:0fc58c1e05, Jan 8 2022, 19:45:58) [Clang 12.0.0
(clang-1200.0.32.29)]
call bug233.py@15 (first=15): def f():
call bug233.py@17 (first=15): fn = lambda: 2
retu bug233.py@18 (first=15): b = 3
--
components: Interpreter Core
keywords: 3.11regression
messages: 410151
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Stray RESUME opcode for unused lambda
versions: Python 3.11
___
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
[issue46225] f_lasti behaves differently for lambdas returned from loops
Ned Batchelder added the comment: Thanks, it does help. While updating coverage.py to use the RESUME information, I found another problem: https://bugs.python.org/issue46314 -- ___ Python tracker <https://bugs.python.org/issue46225> ___ ___ 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
New submission from Ned Batchelder : See the starred line in the trace output for 3.11: $ cat class_def.py class theClass: ''' the docstring. ''' def __init__(self): ''' Another docstring. ''' self.a = 1 $ python3.10 -c "import sys; print(sys.version)" 3.10.1 (main, Dec 14 2021, 08:30:13) [Clang 12.0.0 (clang-1200.0.32.29)] $ python3.10 -m trace --trace class_def.py --- modulename: class_def, funcname: class_def.py(1): class theClass: --- modulename: class_def, funcname: theClass class_def.py(1): class theClass: class_def.py(2): ''' the docstring. ''' class_def.py(3): def __init__(self): $ python3.11 -c "import sys; print(sys.version)" 3.11.0a3+ (heads/main:0fc58c1e05, Jan 8 2022, 19:45:58) [Clang 12.0.0 (clang-1200.0.32.29)] $ python3.11 -m trace --trace class_def.py --- modulename: class_def, funcname: class_def.py(1): class theClass: --- modulename: class_def, funcname: theClass class_def.py(1): class theClass: class_def.py(2): ''' the docstring. ''' class_def.py(1): class theClass:<<<* class_def.py(3): def __init__(self): -- components: Interpreter Core keywords: 3.11regression messages: 410217 nosy: Mark.Shannon, nedbat priority: normal severity: normal status: open title: 3.11: tracing revisits class line after class docstring versions: Python 3.11 ___ 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
[issue46344] 3.11: except/else/if/raise traced incorrectly
New submission from Ned Batchelder :
This code shows a raise inside an except/else/if that isn't run, but
incorrectly appears in the trace output (see the * line):
$ cat arcs_1160.py
def func(x):
try:
b = 6
except ZeroDivisionError:
pass
else:
if x == "raise":
raise ValueError()
finally:
f = 23
func("other")
$ python3.10 -c "import sys; print(sys.version)"
3.10.1 (main, Dec 14 2021, 08:30:13) [Clang 12.0.0 (clang-1200.0.32.29)]
$ python3.10 -m trace --trace arcs_1160.py
--- modulename: arcs_1160, funcname:
arcs_1160.py(1): def func(x):
arcs_1160.py(12): func("other")
--- modulename: arcs_1160, funcname: func
arcs_1160.py(2): try:
arcs_1160.py(3): b = 6
arcs_1160.py(7): if x == "raise":
arcs_1160.py(10): f = 23
$ python3.11 -c "import sys; print(sys.version)"
3.11.0a3+ (heads/main:d24cd49acb, Jan 11 2022, 07:29:41) [Clang 12.0.0
(clang-1200.0.32.29)]
$ python3.11 -m trace --trace arcs_1160.py
--- modulename: arcs_1160, funcname:
arcs_1160.py(1): def func(x):
arcs_1160.py(12): func("other")
--- modulename: arcs_1160, funcname: func
arcs_1160.py(2): try:
arcs_1160.py(3): b = 6
arcs_1160.py(7): if x == "raise":
arcs_1160.py(8): raise ValueError() <<**
arcs_1160.py(10): f = 23
--
components: Interpreter Core
keywords: 3.11regression
messages: 410300
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: 3.11: except/else/if/raise traced incorrectly
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46344>
___
___
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
Ned Batchelder added the comment: Yes, thanks, this fixes it. -- ___ 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
Ned Batchelder added the comment: This fixes the problems I was seeing, thanks. -- ___ 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
[issue46389] 3.11: unused generator comprehensions cause f_lineno==None
New submission from Ned Batchelder :
In Python 3.11, unused generator comprehensions cause trace events with
f_lineno set to None.
%< -
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
if lineno is not None:
line = linecache.getline(__file__, lineno).rstrip()
else:
line = ""
print("{} {!s:4}: {}".format(event[:4], lineno, line))
return trace
print(sys.version)
sys.settrace(trace)
(i for i in [1])
--
$ python3.10 /tmp/runbpo.py
3.10.2 (main, Jan 15 2022, 05:51:59) [Clang 12.0.0 (clang-1200.0.32.29)]
call 17 : (i for i in [1])
exce 17 : (i for i in [1])
retu 17 : (i for i in [1])
$ python3.11 /tmp/runbpo.py
3.11.0a4 (main, Jan 14 2022, 18:14:29) [Clang 12.0.0 (clang-1200.0.32.29)]
call None:
exce None:
retu None:
--
components: Interpreter Core
keywords: 3.11regression
messages: 410643
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: 3.11: unused generator comprehensions cause f_lineno==None
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46389>
___
___
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?
New submission from Ned Batchelder : The sqlite3 library implicitly creates the database if the requested file doesn't exist. I would like to be able to avoid that implicit creation. (Actually, it would be enough to know whether I had created the database, but the underlying SQLite library doesn't seem to indicate that.) The C code currently hard-codes the SQLite flag to create the database if it doesn't exist: rc = sqlite3_open_v2(database, &db, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | (uri ? SQLITE_OPEN_URI : 0), NULL); Could we make this an option, so the Python code could avoid implicit creation? -- components: Library (Lib) messages: 410704 nosy: nedbat priority: normal severity: normal status: open title: Enhance sqlite3 to avoid implicit creation? ___ 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?
Ned Batchelder added the comment: @Erlend: thanks for the URI tip, I missed that as a possibility in the SQLite docs. -- ___ 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?
Ned Batchelder added the comment: BTW, I'm fine with this being closed, since the functionality I wanted is available and documented. -- ___ 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
[issue42197] Disable automatic update of frame locals during tracing
Ned Batchelder added the comment: Off the top of my head, I'm not sure this affects coverage.py at all, but I could be missing something. Does PR 23028 have all the changes, or is there some other python/cpython branch I can test with? -- ___ Python tracker <https://bugs.python.org/issue42197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42197] Disable automatic update of frame locals during tracing
Ned Batchelder added the comment: I ran the coverage.py test suite using https://github.com/faster-cpython/cpython/tree/dont-fast-to-locals-in-trampoline, and there were no failures. -- ___ Python tracker <https://bugs.python.org/issue42197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42197] Disable automatic update of frame locals during tracing
Ned Batchelder added the comment: And btw, the tests with that branch ran at least twice as fast as with 3.10! -- ___ Python tracker <https://bugs.python.org/issue42197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] return value of builtins is not clearly indicated
Ned Batchelder added the comment: > When you state the obvious... Obvious to who? New learners coming to Python don't know the same things as people with experience. -- nosy: +nedbat ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] return value of builtins is not clearly indicated
Ned Batchelder added the comment: What we're debating here is a micro-cosm of the broader "documentation philosophy" questions that I'm hoping the Documentation WG can iron out. What is "obvious"? Is it obvious that print returns None when file.write does not? Why does "exec" explicitly say it returns None, and no beginners were harmed, but having "print" say it returns None would be bad? -- ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46911] Early tracing has lineno=None for modules
New submission from Ned Batchelder :
Coverage.py has a trick to measure the early execution of stdlib modules. It
has an "encodings.py" file that sets a trace function, then gets out of the way
to let the real encodings.py execute. In 3.11.0a5, that early trace function
gets None values for the line numbers when modules were first executed.
To reproduce, create two files, encodings.py and prog.py:
--- 8< --
# encodings.py
import sys
class FullCoverageTracer:
def __init__(self):
self.traces = []
def fullcoverage_trace(self, *args):
frame, event, arg = args
if frame.f_lineno is None:
self.traces.append((frame.f_code.co_name, frame.f_code.co_filename))
return self.fullcoverage_trace
sys.settrace(FullCoverageTracer().fullcoverage_trace)
parentdir = max(filter(__file__.startswith, sys.path), key=len)
sys.path.remove(parentdir)
del sys.modules['encodings']
import encodings
-
--- 8< --
# prog.py
import sys
print(sys.version)
trace = sys.gettrace()
print("None traces:", trace.__self__.traces)
print("Hello")
-
Then run:
% PYTHONPATH=$(pwd) python3.10 prog.py
3.10.2 (main, Jan 15 2022, 05:51:59) [Clang 12.0.0 (clang-1200.0.32.29)]
None traces: []
Hello
% PYTHONPATH=$(pwd) python3.11 prog.py
3.11.0a5 (main, Feb 3 2022, 19:11:58) [Clang 12.0.0 (clang-1200.0.32.29)]
None traces: [('',
'/usr/local/pyenv/pyenv/versions/3.11.0a5/lib/python3.11/encodings/__init__.py'),
('', ''), ('',
'/usr/local/pyenv/pyenv/versions/3.11.0a5/lib/python3.11/encodings/aliases.py'),
('',
'/usr/local/pyenv/pyenv/versions/3.11.0a5/lib/python3.11/encodings/utf_8.py'),
('', ''), ('', ''), ('',
''), ('', ''), ('', ''),
('', ''), ('', ''),
('', ''), ('', ''),
('', ''), ('',
'/System/Volumes/Data/root/src/bugs/fullcov/prog.py')]
Hello
--
components: Interpreter Core
keywords: 3.11regression
messages: 414438
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Early tracing has lineno=None for modules
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46911>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46389] 3.11: unused generator comprehensions cause f_lineno==None
Ned Batchelder added the comment: Yes, this is fixed, thanks. -- ___ Python tracker <https://bugs.python.org/issue46389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46911] Early tracing has lineno=None for modules
Ned Batchelder added the comment: Maybe I'm missing something during normal execution, but I'm only seeing this effect now during this super-early encodings.py trick. I don't mind just special-casing the Nones in this case. -- ___ Python tracker <https://bugs.python.org/issue46911> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13530] Docs for os.lseek neglect to mention what it returns
New submission from Ned Batchelder : The docs for os.lseek don't make any mention of its return value. I believe it's the new offset in the file, but I'm not sure if there are other subtleties to be mentioned. -- assignee: docs@python components: Documentation messages: 148861 nosy: docs@python, nedbat priority: normal severity: normal status: open title: Docs for os.lseek neglect to mention what it returns versions: Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue13530> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13548] Invalid 'line' tracer event on pass within else clause
Changes by Ned Batchelder : -- nosy: +nedbat ___ Python tracker <http://bugs.python.org/issue13548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12397] re match object methods have no docstrings
New submission from Ned Batchelder :
If I have a match object in hand, and ask for help on its methods, there is no
information:
>>> m = re.match("a", "a")
>>> help(m.group)
Help on built-in function group:
group(...)
>>>
--
messages: 138937
nosy: nedbat
priority: normal
severity: normal
status: open
title: re match object methods have no docstrings
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue12397>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11561] "coverage" of Python regrtest cannot see initial import of libs
Ned Batchelder added the comment: The tip of the coverage.py repo (https://bitbucket.org/ned/coveragepy) has a new implementation of the encodings hack which seems to work well. Of course, an option to run a module before anything else in the interpreter would make the whole thing much simpler. -- ___ Python tracker <http://bugs.python.org/issue11561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11846] Remove non-guaranteed implementation details from docs.
Changes by Ned Batchelder : -- nosy: +nedbat ___ Python tracker <http://bugs.python.org/issue11846> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11992] sys.settrace doesn't disable tracing if a local trace function returns None
New submission from Ned Batchelder :
The docs say:
The trace function is invoked (with event set to 'call') whenever a new
local scope is entered; it should return a reference to a local trace function
to be used that scope, or None if the scope shouldn’t be traced.
The local trace function should return a reference to itself (or to another
function for further tracing in that scope), or None to turn off tracing in
that scope.
It's that last part that's wrong: returning None from the trace function only
has an effect on the first call in a new frame. Once the trace function
returns a function for a frame, returning None from subsequent calls is
ignored. A "local trace function" can't turn off tracing in its scope.
To demonstrate:
import sys
UPTO_LINE = 1
def t(frame, event, arg):
num = frame.f_lineno
print("line %d" % num)
if num < UPTO_LINE:
return t
def try_it():
print("twelve")
print("thirteen")
print("fourteen")
print("fifteen")
UPTO_LINE = 1
sys.settrace(t)
try_it()
UPTO_LINE = 13
sys.settrace(t)
try_it()
Produces:
line 11
twelve
thirteen
fourteen
fifteen
line 11
line 12
twelve
line 13
thirteen
line 14
fourteen
line 15
fifteen
line 15
The first call to try_it() returns None immediately, preventing tracing for the
rest of the function. The second call returns None at line 13, but the rest of
the function is traced anyway. This behavior is the same in all versions from
2.3 to 3.2, in fact, the 100 lines of code in sysmodule.c responsible for
Python tracing functions are completely unchanged through those versions.
--
components: Library (Lib)
messages: 135089
nosy: nedbat
priority: normal
severity: normal
status: open
title: sys.settrace doesn't disable tracing if a local trace function returns
None
type: behavior
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue11992>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11992] sys.settrace doesn't disable tracing if a local trace function returns None
Changes by Ned Batchelder : -- assignee: -> nedbat ___ Python tracker <http://bugs.python.org/issue11992> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11065] Fatal "can't locate locale" errors when zip file with directories is on the PYTHONPATH.
New submission from Ned Batchelder : Run this shell script against 3.2, and it will fail. Against 3.1, it succeeds. I've been running tests on Ubuntu 10.10. mkdir -p sub cat >sub/modzip.py < <http://bugs.python.org/issue11065> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11065] Fatal "can't locate locale" errors when zip file with directories is on the PYTHONPATH.
Ned Batchelder added the comment: With help from ned_deily in #python-dev, we confirmed this is a dup of http://bugs.python.org/issue10955, and is already fixed. -- resolution: -> duplicate ___ Python tracker <http://bugs.python.org/issue11065> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
New submission from Ned Batchelder : 2.6.4 had been working fine for me. Today, though, it will not stay up. I run the Django development server on Windows 7, and 2.6.4 is repeatedly crashing on me: This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Validating models... Assertion failed: w32_sharedptr->size == sizeof(W32_EH_SHARED), file ../../gcc-3.4.5/gcc/config/i386/w32-shared-ptr.c, line 247 I have no idea what's changed between yesterday and today. -- components: None messages: 100739 nosy: nedbat severity: normal status: open title: w32-shared-ptr.c assertion on Windows 7 with 2.6.4 type: crash versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
Ned Batchelder added the comment: I got it from python.org, the .msi Windows installer: 03/02/10 05:27:37p 14,890,496 \kit\python-2.6.4.msi -- ___ Python tracker <http://bugs.python.org/issue8101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
Ned Batchelder added the comment: I tried rebooting my PC, but the problem persists. -- ___ Python tracker <http://bugs.python.org/issue8101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8101] w32-shared-ptr.c assertion on Windows 7 with 2.6.4
Ned Batchelder added the comment: Yup, you're both right! I had a C extension (for coverage.py) built for 2.5 in the 2.6 path. Sorry for the false alarm. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue8101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
New submission from Ned Batchelder <[EMAIL PROTECTED]>: When tracing line execution with sys.settrace, a particular code structure fails to report an executed line. The line is a continue statement after an if condition in which the if condition is true every time it is executed. Attached is a file with two copies of the same code, except in the first the if condition is always true, and in the second it is sometimes true. In the first, trace.py reports that the continue is never executed, even though it is (as evidenced from the values of a, b, and c after execution). In the second code, the continue is properly reported. This bug has been present since version 2.3. 2.2 does not exhibit it (trace.py didn't exist in 2.2, but coverage.py shows the problem also). To see the problem, execute "trace.py -c -m continue.py". Then continue.py.cover will show: 1: a = b = c = 0 101: for n in range(100): 100: if n % 2: 50: if n % 4: 50: a += 1 >>>>>> continue else: 50: b += 1 50: c += 1 1: assert a == 50 and b == 50 and c == 50 1: a = b = c = 0 101: for n in range(100): 100: if n % 2: 50: if n % 3: 33: a += 1 17: continue else: 50: b += 1 50: c += 1 1: assert a == 33 and b == 50 and c == 50 -- components: Interpreter Core files: continue.py messages: 64692 nosy: nedbat severity: normal status: open title: Line tracing of continue after always-taken if is incorrect type: behavior versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9888/continue.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Ned Batchelder <[EMAIL PROTECTED]> added the comment: I see that the cause of the problem is the peephole optimizer. That doesn't mean this isn't a problem. I am measuring the code coverage of a set of tests, and one of my lines is being marked as not executed. This is not the fault of the tests, because in fact, without the optimization, the line would be executed. Conceptually, the line has been executed (the loop is restarted, rather than execution continuing). I don't know what the solution to this is. Some options include fixing the line tracing code to somehow indicate that the continue was executed; or providing a way to disable peephole optimization for times when accurate execution tracing is more important than speed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Ned Batchelder <[EMAIL PROTECTED]> added the comment: I recognize that this is an unusual case, but it did come up in the real world. I found this while measuring test coverage, and the continue line was marked as not executed, when it was. I don't understand "when the peepholer is moved", so maybe you are right that this will no longer be an issue. But it seems to me to be endemic to code optimization to lose the one-to-one correspondence between source lines and ranges of bytecodes. And as the compiler becomes more complex and performs more optmizations, problems like this will likely increase, no? In any case, I'd like to know more about the changes planned for the AST and compiler... __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Ned Batchelder <[EMAIL PROTECTED]> added the comment: Raymond, do you have a cannon-less recommendation of how to kill this particular mosquito? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2516] Instance methods are misreporting the number of arguments
Changes by Ned Batchelder <[EMAIL PROTECTED]>: -- nosy: +nedbat __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2516> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Ned Batchelder <[EMAIL PROTECTED]> added the comment: It's hard for me to agree with your assessment that for no practical good would come from disabling the optimizer. Broadly speaking, there are two types of code execution: the vast majority of the time, you execute the code so that it can do its work. In this case, speed is most important, and the peephole optimizer is a good thing. But another important case is when you need to reason about the code. This second case includes coverage testing, debugging, and other types of analysis. Compiled languages have long recognized the need for both types of compilation, which is why they support disabling optimization entirely. As Python becomes more complex, and more broadly deployed, the needs of the two types of execution will diverge more and more. More complex optimizations will be attempted in order to squeeze out every last drop of performance. And more complex tools to reason about the code will be developed to provide rich support to those using Python for complex development. I see discussion here of moving the optimizer to the AST level instead of the bytecode level. This won't change the situation. The optimizer will still interfere with analysis tools. As a developer of analysis tools, what should I tell my users when their code behaves mysteriously? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47046] Add `f_state` attribute to FrameObjects.
Ned Batchelder added the comment: These look great. Currently, coverage.py only tries to distinguish between return/yield, which I guess will now be COMPLETED and SUSPENDED? -- ___ Python tracker <https://bugs.python.org/issue47046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47085] missing frame.f_lineno on JUMP_ABSOLUTE
Change by Ned Batchelder : -- nosy: +Mark.Shannon, nedbat ___ Python tracker <https://bugs.python.org/issue47085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47163] "unterminated subpattern" in valid regex if re.VERBOSE is used
New submission from Ned Batchelder : In this code, the same regex is compiled with and without re.VERBOSE. Without, it compiles fine. With, it fails with an "unterminated subpattern" error. list_num_rx1 = r"""(?P\()?(\d+|#|[a-z])(?(paren)\)|\.)""" list_num_rx2 = r"""(?x)(?P\()?(\d+|#|[a-z])(?(paren)\)|\.)""" # This works: re.compile(list_num_rx1) # Either of these fails: re.compile(list_num_rx1, flags=re.VERBOSE) re.compile(list_num_rx2) (What I really wanted was this, but the error happens without the multiline string:) list_num_rx = r"""(?x) (?P\()? # maybe an opening paren (\d+|#|[a-z]) # the number: 123, or #, or a-z (?(paren) # if we had an opening paren.. \)| # then we need a closing paren \. # otherwise a dot. ) """ -- components: Regular Expressions messages: 416340 nosy: ezio.melotti, mrabarnett, nedbat priority: normal severity: normal status: open title: "unterminated subpattern" in valid regex if re.VERBOSE is used ___ Python tracker <https://bugs.python.org/issue47163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47163] "unterminated subpattern" in valid regex if re.VERBOSE is used
Ned Batchelder added the comment: I realized my mistake... never mind! -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17894] Edits to descriptor howto
Ned Batchelder added the comment: I think it's a bad precedent to have pages in the official docs that belong to a single author. If you want to maintain that kind of control, it should go on your blog. Part of the agreement for having material added to the official docs should be the understanding that they are fair game for community contributions. -- ___ Python tracker <https://bugs.python.org/issue17894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17894] Edits to descriptor howto
Change by Ned Batchelder : -- resolution: rejected -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue17894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38735] PYTHONPYCACHEPREFIX fails when importing a module from the root ("/")
New submission from Ned Batchelder :
On the manylinux docker images, the current directory is "/".
If I create a file there and try to import it with PYTHONPYCACHEPREFIX set, I
get a stack trace:
$ docker run -it --init --rm -v `pwd`:/io quay.io/pypa/manylinux1_x86_64 bash
[root@29d75403d7d1 /]# cat > foo.py
a = 1
[root@29d75403d7d1 /]# /opt/python/cp38-cp38/bin/python
Python 3.8.0 (default, Oct 30 2019, 22:13:22)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
>>> foo.a
1
>>>
[root@29d75403d7d1 /]# PYTHONPYCACHEPREFIX=/opt/pyc
/opt/python/cp38-cp38/bin/python
Python 3.8.0 (default, Oct 30 2019, 22:13:22)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
Traceback (most recent call last):
File "", line 1, in
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 657, in _load_unlocked
File "", line 562, in module_from_spec
File "", line 541, in _init_module_attrs
File "", line 382, in cached
File "", line 427, in _get_cached
File "", line 352, in cache_from_source
IndexError: string index out of range
>>>
--
messages: 356188
nosy: nedbat
priority: normal
severity: normal
status: open
title: PYTHONPYCACHEPREFIX fails when importing a module from the root ("/")
___
Python tracker
<https://bugs.python.org/issue38735>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42246] Implement PEP 626 -- Precise line numbers for debugging
Ned Batchelder added the comment: Is there a reason PEP 626 isn't yet mentioned in https://docs.python.org/3.10/whatsnew/3.10.html ? -- ___ Python tracker <https://bugs.python.org/issue42246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42823] Incorrect frame.f_lineno when frame.f_trace is set
Change by Ned Batchelder : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
Change by Ned Batchelder : -- nosy: +nedbat ___ Python tracker <https://bugs.python.org/issue43833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43933] Regression in python3.10 with traceback frame having lineno of -1
Ned Batchelder added the comment: Mark, you say: > The traceback for 3.9 is incorrect, the program is not on line 10 when > __exit__ is called. It's kind of not on any line in main(), but line 10 is the most useful line to indicate. It's the last bit of the user's code that was running, and it is the reason for leaving the with statement. -- ___ Python tracker <https://bugs.python.org/issue43933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41129] setup.py test for macOS SDK files may incorrectly classify files in other file systems
Ned Batchelder added the comment: I just spent an hour debugging this problem. I don't understand the intricacies of how setup.py is looking for files, but more and more people will have Catalina and the issue this presents. I can confirm that Andrew's suggestion works. Can we get this applied to 3.10? -- nosy: +nedbat ___ Python tracker <https://bugs.python.org/issue41129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43933] Regression in python3.10 with traceback frame having lineno of -1
Ned Batchelder added the comment: I'm trying to see if these changes affect coverage.py, but pytest 6.2.3 fails with: === CPython 3.10.0a7+ (rev 558df90109) with Python tracer (.tox/anypy/bin/python) === ImportError while loading conftest '/Users/nedbatchelder/coverage/trunk/tests/conftest.py'. TypeError: required field "lineno" missing from alias Is this something I am doing wrong? -- ___ Python tracker <https://bugs.python.org/issue43933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41129] setup.py test for macOS SDK files may incorrectly classify files in other file systems
Change by Ned Batchelder : -- keywords: +patch pull_requests: +24475 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25785 ___ Python tracker <https://bugs.python.org/issue41129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43933] Regression in python3.10 with traceback frame having lineno of -1
Ned Batchelder added the comment: Thanks, tip of pytest works for me. Is this error going to happen for everyone testing with 3.10b1? If so, can we get a release of pytest? -- ___ Python tracker <https://bugs.python.org/issue43933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43933] Regression in python3.10 with traceback frame having lineno of -1
Ned Batchelder added the comment: The pytest failure still happens with 3.10.0b1 and pytest 6.2.3. I'm asking if pytest can make a release to update. -- ___ Python tracker <https://bugs.python.org/issue43933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43933] Regression in python3.10 with traceback frame having lineno of -1
Ned Batchelder added the comment:
Mark, I'm not clear if the line number can still be None in some circumstances.
With this code (from site.py in the stdlib):
545: def execsitecustomize():
546: """Run custom site specific code, if available."""
547: try:
548: try:
549: import sitecustomize
550: except ImportError as exc:
551: if exc.name == 'sitecustomize':
552: pass
553: else:
554: raise
555: except Exception as err:
556: if sys.flags.verbose:
557: sys.excepthook(*sys.exc_info())
558: else:
559: sys.stderr.write(
560: "Error in sitecustomize; set PYTHONVERBOSE for
traceback:\n"
561: "%s: %s\n" %
562: (err.__class__.__name__, err))
I get traces with these events and line numbers:
exception 549 (ModuleNotFoundError("No module named 'sitecustomize'"))
line 550
line 551
line 552
return None
Is this what you expected?
--
___
Python tracker
<https://bugs.python.org/issue43933>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44088] traced line number can be None
New submission from Ned Batchelder :
Mark, I'm not clear if the line number can still be None in some circumstances.
With this code (from site.py in the stdlib):
545: def execsitecustomize():
546: """Run custom site specific code, if available."""
547: try:
548: try:
549: import sitecustomize
550: except ImportError as exc:
551: if exc.name == 'sitecustomize':
552: pass
553: else:
554: raise
555: except Exception as err:
556: if sys.flags.verbose:
557: sys.excepthook(*sys.exc_info())
558: else:
559: sys.stderr.write(
560: "Error in sitecustomize; set PYTHONVERBOSE for
traceback:\n"
561: "%s: %s\n" %
562: (err.__class__.__name__, err))
I get traces with these events and line numbers:
exception 549 (ModuleNotFoundError("No module named 'sitecustomize'"))
line 550
line 551
line 552
return None
Is this what you expected?
--
assignee: Mark.Shannon
messages: 393319
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: traced line number can be None
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44088>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43933] Regression in python3.10 with traceback frame having lineno of -1
Ned Batchelder added the comment: BTW, I created a separate issue about this: https://bugs.python.org/issue44088 because I wasn't sure if I should continue on this one, sorry. Feel free to close either one. -- ___ Python tracker <https://bugs.python.org/issue43933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43933] Regression in python3.10 with traceback frame having lineno of -1
Ned Batchelder added the comment: Thanks, this fixes my issue. -- ___ Python tracker <https://bugs.python.org/issue43933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44298] 3.10.0b2 traces with-exit before the break that caused the exit
New submission from Ned Batchelder :
Python 3.10 now traces back to with statements when exiting the with block.
When the exit is a break statement, the with exit is visited before the break
statement is. This seems confusing.
--- 8< -
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
def doit():
for i in range(2):
with open("test", "w") as f:
a = 13
b = 14
break
c = 16
print(sys.version)
sys.settrace(trace)
doit()
--- 8< -
3.10.0b2 (default, Jun 3 2021, 05:27:13) [Clang 12.0.0 (clang-1200.0.32.29)]
call 10: def doit():
line 11: for i in range(2):
line 12: with open("test", "w") as f:
line 13: a = 13
line 14: b = 14
line 12: with open("test", "w") as f:
line 15: break
line 16: c = 16
retu 16: c = 16
Shouldn't we get a trace for line 15 (break), then line 12 (with-exit), then
line 15 again, then line 16?
--
assignee: Mark.Shannon
components: Interpreter Core
messages: 394990
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: 3.10.0b2 traces with-exit before the break that caused the exit
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44298>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44298] 3.10.0b2 traces with-exit before the break that caused the exit
Ned Batchelder added the comment:
(I'm not sure whether to create other issues for further details)
I'm also seeing a return in a with will trace withexit/return for a plain
"return" statement, but return/withexit/return for a return with a value
("return 17").
I would expect that a statement causing an exit from a with block would always
be traced before the with-exit.
--
___
Python tracker
<https://bugs.python.org/issue44298>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44298] 3.10.0b2 traces with-exit before the break that caused the exit
Ned Batchelder added the comment: Thanks for the quick turnaround, this works! -- ___ Python tracker <https://bugs.python.org/issue44298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension
Change by Ned Batchelder : -- nosy: +nedbat ___ Python tracker <https://bugs.python.org/issue6> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44450] Generator expressions trace differently on Windows than on Mac
New submission from Ned Batchelder :
Here is a trace involving generator expressions. Using 3.10.0b3 on Mac, there
are "line" events within the expression. Those events are missing on Windows.
--- 8< ---
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
def doit():
o = ((1,2), (3,4))
o = (a for a in o)
for tup in o:
x = tup[0]
y = tup[1]
print(sys.version)
sys.settrace(trace)
doit()
---
When run on Mac, it produces this output:
3.10.0b3 (default, Jun 18 2021, 06:43:38) [Clang 12.0.0 (clang-1200.0.32.29)]
call 10: def doit():
line 11: o = ((1,2), (3,4))
line 12: o = (a for a in o)
line 13: for tup in o:
call 12: o = (a for a in o)
line 12: o = (a for a in o)
retu 12: o = (a for a in o)
line 14: x = tup[0]
line 15: y = tup[1]
line 13: for tup in o:
call 12: o = (a for a in o)
line 12: o = (a for a in o)
retu 12: o = (a for a in o)
line 14: x = tup[0]
line 15: y = tup[1]
line 13: for tup in o:
call 12: o = (a for a in o)
retu 12: o = (a for a in o)
retu 13: for tup in o:
When run on Windows, it produces this output:
3.10.0b3 (tags/v3.10.0b3:865714a, Jun 17 2021, 20:39:25) [MSC v.1929 64 bit
(AMD64)]
call 10: def doit():
line 11: o = ((1,2), (3,4))
line 12: o = (a for a in o)
line 13: for tup in o:
call 12: o = (a for a in o)
retu 12: o = (a for a in o)
line 14: x = tup[0]
line 15: y = tup[1]
line 13: for tup in o:
call 12: o = (a for a in o)
retu 12: o = (a for a in o)
line 14: x = tup[0]
line 15: y = tup[1]
line 13: for tup in o:
call 12: o = (a for a in o)
retu 12: o = (a for a in o)
retu 13: for tup in o:
On Windows, the "line 12" events are missing.
--
components: Interpreter Core
keywords: 3.10regression
messages: 396050
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Generator expressions trace differently on Windows than on Mac
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44450>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44450] Generator expressions trace differently on Windows than on Mac
Ned Batchelder added the comment: This happens with all the 3.10 betas, and does not happen in 3.9 and earlier: https://github.com/nedbat/coveragepy/runs/2864611225 (Sorry, other failures with earlier 3.10 betas obscured the mac/win difference.) -- ___ Python tracker <https://bugs.python.org/issue44450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44450] Generator expressions trace differently on Windows than on Mac
Ned Batchelder added the comment: I tried adding that rewritten doit as a new test, and it does not show a mac/win difference on 3.9. In fact, it doesn't show a mac/win difference on 3.10! https://github.com/nedbat/coveragepy/actions/runs/956791631 -- ___ Python tracker <https://bugs.python.org/issue44450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44450] Generator expressions trace differently on Windows than on Mac
Ned Batchelder added the comment: This was with 3.10.0b3. I haven't got a way (yet) to build with my own-built versions of CPython. -- ___ Python tracker <https://bugs.python.org/issue44450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44570] 3.10.0b3 doesn't trace line events for return in some cases
New submission from Ned Batchelder :
(from https://github.com/nedbat/coveragepy/issues/1184)
This code runs the return statement on line 17 twice. The second time, there
is a "line" event and then a "return" event for that line. But the first time,
there is only a "return" event:
--- 8< ---
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
def foo(x):
if x:
try:
1/(x - 1)
except ZeroDivisionError:
pass
return x
def test_foo():
for i in range(2):
foo(i)
print(sys.version)
sys.settrace(trace)
test_foo()
-
I get this output with 3.10.0b3:
3.10.0b3 (default, Jun 18 2021, 06:43:38) [Clang 12.0.0 (clang-1200.0.32.29)]
call 19: def test_foo():
line 20: for i in range(2):
line 21: foo(i)
call 10: def foo(x):
line 11: if x:
retu 17: return x
line 20: for i in range(2):
line 21: foo(i)
call 10: def foo(x):
line 11: if x:
line 12: try:
line 13: 1/(x - 1)
exce 13: 1/(x - 1)
line 14: except ZeroDivisionError:
line 15: pass
line 17: return x
retu 17: return x
line 20: for i in range(2):
retu 20: for i in range(2):
Shouldn't there be a "line" event for both invocations?
--
components: Interpreter Core
keywords: 3.10regression
messages: 397024
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: 3.10.0b3 doesn't trace line events for return in some cases
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44570>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44570] 3.10.0b3 doesn't trace line events for return in some cases
Ned Batchelder added the comment: I can confirm that those two pull requests fix the problem reported here. -- ___ Python tracker <https://bugs.python.org/issue44570> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44600] match/case statements trace incorrectly in 3.10.0b4
New submission from Ned Batchelder :
Some simple match/case statements show incorrect tracing. Below is the code to
run, as well as the output. Output lines with initial stars are incorrect:
they incorrectly indicate that case bodies are executing when they are not.
Sorry for the bulk here, I wanted to give you all the cases I had.
-- 8< -
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
def match_with_default():
for command in ["huh", "go home", "go n"]:
print(command)
match command.split():
case ["go", direction] if direction in "nesw":
match = f"go: {direction}"
case ["go", _]:
match = "no go"
case _:
match = "default"
print(match)
def match_with_wildcard():
for command in ["huh", "go home", "go n"]:
print(command)
match command.split():
case ["go", direction] if direction in "nesw":
match = f"go: {direction}"
case ["go", _]:
match = "no go"
case x:
match = f"default: {x}"
print(match)
def match_without_wildcard():
match = None
for command in ["huh", "go home", "go n"]:
print(command)
match command.split():
case ["go", direction] if direction in "nesw":
match = f"go: {direction}"
case ["go", _]:
match = "no go"
print(match)
print(sys.version)
sys.settrace(trace)
match_with_default()
match_with_wildcard()
match_without_wildcard()
-- 8< -
Output:
3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
call 10: def match_with_default():
line 11: for command in ["huh", "go home", "go n"]:
line 12: print(command)
huh
line 13: match command.split():
line 14: case ["go", direction] if direction in "nesw":
line 15: match = f"go: {direction}"
line 16: case ["go", _]:
* line 17: match = "no go"
line 19: match = "default"
line 20: print(match)
default
line 11: for command in ["huh", "go home", "go n"]:
line 12: print(command)
go home
line 13: match command.split():
line 14: case ["go", direction] if direction in "nesw":
line 16: case ["go", _]:
line 17: match = "no go"
line 20: print(match)
no go
line 11: for command in ["huh", "go home", "go n"]:
line 12: print(command)
go n
line 13: match command.split():
line 14: case ["go", direction] if direction in "nesw":
line 15: match = f"go: {direction}"
line 20: print(match)
go: n
line 11: for command in ["huh", "go home", "go n"]:
retu 11: for command in ["huh", "go home", "go n"]:
call 22: def match_with_wildcard():
line 23: for command in ["huh", "go home", "go n"]:
line 24: print(command)
huh
line 25: match command.split():
line 26: case ["go", direction] if direction in "nesw":
* line 27: match = f"go: {direction}"
line 28: case ["go", _]:
* line 29: match = "no go"
line 30: case x:
line 31: match = f"default: {x}"
line 32: print(match)
default: ['huh']
line 23: for command in ["huh", "go home", "go n"]:
line 24: print(command)
go home
line 25: match command.split():
line 26: case ["go", direction] if direction in "nesw":
line 28: case ["go", _]:
line 29: match = "no go"
line 32: print(match)
no go
line 23: for command in ["huh", "go home", "go n"]:
line 24: print(command)
go n
line 25:
[issue44616] Incorrect tracing for "except" with variable
New submission from Ned Batchelder :
This construct isn't traced properly:
except ExceptionName as var:
if something:
raise
Here's a reproducer:
-- 8< -
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
def f(x):
try:
1/0
except ZeroDivisionError as error:
if x:
raise
return 12
print(sys.version)
sys.settrace(trace)
for x in [0, 1]:
try:
print(f(x))
except:
print("oops")
---
When run with 3.10.0b4, it produces this output:
3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
call 10: def f(x):
line 11: try:
line 12: 1/0
exce 12: 1/0
line 13: except ZeroDivisionError as error:
line 14: if x:
* line 15: raise
line 16: return 12
retu 16: return 12
12
call 10: def f(x):
line 11: try:
line 12: 1/0
exce 12: 1/0
line 13: except ZeroDivisionError as error:
line 14: if x:
line 15: raise
retu 15: raise
oops
The starred line claims that raise is being run, but it is not run at that
point.
The variable on the except clause is important. If you change that line to
"except ZeroDivisionError:", then the output is correct:
3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
call 10: def f(x):
line 11: try:
line 12: 1/0
exce 12: 1/0
line 13: except ZeroDivisionError:
line 14: if x:
line 16: return 12
retu 16: return 12
12
call 10: def f(x):
line 11: try:
line 12: 1/0
exce 12: 1/0
line 13: except ZeroDivisionError:
line 14: if x:
line 15: raise
retu 15: raise
oops
--
components: Interpreter Core
keywords: 3.10regression
messages: 397365
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Incorrect tracing for "except" with variable
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44616>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44616] Incorrect tracing for "except" with variable
Ned Batchelder added the comment: Based on https://github.com/nedbat/coveragepy/issues/1187, btw -- ___ Python tracker <https://bugs.python.org/issue44616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44621] Python 3.9 traces async for/else incorrectly
New submission from Ned Batchelder :
Python 3.9 traces this code incorrectly. Note: 3.8 and 3.10 are correct, only
3.9 gets it wrong.
---
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
import asyncio
async def async_gen():
yield 13
async def async_test():
global a
a = 17
async for i in async_gen():
print(i + 19)
else:
a = 21
print(sys.version)
sys.settrace(trace)
asyncio.run(async_test())
assert a == 21
--
The starred line shows a trace of a statement that is not executed:
3.9.6 (default, Jul 13 2021, 07:21:14)
[Clang 12.0.0 (clang-1200.0.32.29)]
call 15: async def async_test():
line 17: a = 17
line 18: async for i in async_gen():
call 12: async def async_gen():
line 13: yield 13
retu 13: yield 13
exce 18: async for i in async_gen():
line 19: print(i + 19)
32
line 18: async for i in async_gen():
call 13: yield 13
retu 13: yield 13
exce 18: async for i in async_gen():
* line 19: print(i + 19)
line 21: a = 21
retu 21: a = 21
--
components: Interpreter Core
keywords: 3.9regression
messages: 397393
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Python 3.9 traces async for/else incorrectly
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44621>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44621] Python 3.9 traces async for/else incorrectly
Ned Batchelder added the comment: The corresponding coverage.py issue: https://github.com/nedbat/coveragepy/issues/1158 -- ___ Python tracker <https://bugs.python.org/issue44621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44622] async-for loops are traced incorrectly in Python 3.10
New submission from Ned Batchelder :
In Python 3.10, the traces at the end of an async-for loop are incorrect and
different than at the end of a for-loop.
--
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
import asyncio
class AsyncIter:
def __init__(self, items): self.items = items
async def __aiter__(self):
for i in self.items: yield i
async def test1():
async for i in AsyncIter([1]):
print(f"test1 {i}")
def test2():
for i in [1]:
print(f"test2 {i}")
print(sys.version)
sys.settrace(trace)
asyncio.run(test1())
test2()
In 3.7, 3.8 and 3.9, the two for loops behave the same: the loop jumps back to
the "for" statement, and then returns (the arrowed lines):
3.9.5 (default, May 5 2021, 06:50:43)
[Clang 12.0.0 (clang-1200.0.32.29)]
call 18: async def test1():
line 19: async for i in AsyncIter([1]):
call 13: def __init__(self, items): self.items = items
line 13: def __init__(self, items): self.items = items
retu 13: def __init__(self, items): self.items = items
call 15: async def __aiter__(self):
line 16: for i in self.items: yield i
retu 16: for i in self.items: yield i
exce 19: async for i in AsyncIter([1]):
line 20: print(f"test1 {i}")
test1 1
line 19: async for i in AsyncIter([1]):
call 16: for i in self.items: yield i
line 16: for i in self.items: yield i
retu 16: for i in self.items: yield i
exce 19: async for i in AsyncIter([1]):
> retu 19: async for i in AsyncIter([1]):
call 22: def test2():
line 23: for i in [1]:
line 24: print(f"test2 {i}")
test2 1
line 23: for i in [1]:
> retu 23: for i in [1]:
In 3.10, the for loop behaves the same, but now the async-for traces the body
once more when it doesn't execute, and returns from the body of the loop (the
starred line):
3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
call 18: async def test1():
line 19: async for i in AsyncIter([1]):
call 13: def __init__(self, items): self.items = items
line 13: def __init__(self, items): self.items = items
retu 13: def __init__(self, items): self.items = items
call 15: async def __aiter__(self):
line 16: for i in self.items: yield i
retu 16: for i in self.items: yield i
exce 19: async for i in AsyncIter([1]):
line 20: print(f"test1 {i}")
test1 1
line 19: async for i in AsyncIter([1]):
call 16: for i in self.items: yield i
line 16: for i in self.items: yield i
retu 16: for i in self.items: yield i
exce 19: async for i in AsyncIter([1]):
* line 20: print(f"test1 {i}")
retu 20: print(f"test1 {i}")
call 22: def test2():
line 23: for i in [1]:
line 24: print(f"test2 {i}")
test2 1
line 23: for i in [1]:
> retu 23: for i in [1]:
--
components: Interpreter Core
keywords: 3.10regression
messages: 397396
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: async-for loops are traced incorrectly in Python 3.10
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44622>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44626] Incorrect tracing of nested if/if/for/yield
New submission from Ned Batchelder :
In Python 3.10, this code is traced incorrectly. I don't know if there's a
simpler format that would show the problem. This code is already simplified
from https://github.com/nedbat/coveragepy/issues/1188.
--
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
print(sys.version)
sys.settrace(trace)
def f(a, p, z):
if p:
print(f"{a=}")
if a:
if z:
for x in [1,2]:
yield x
else:
for x in [1,2]:
yield x
else:
print("nope")
import itertools
for a, p, z in itertools.product([0, 1], repeat=3):
list(f(a, p, z))
Running this with 3.10.0b4 produces this output. The starred lines show a is
false, but tracing then indicates a line which is not executed:
3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
call 13: def f(a, p, z):
line 14: if p:
line 24: print("nope")
nope
retu 24: print("nope")
call 13: def f(a, p, z):
line 14: if p:
line 24: print("nope")
nope
retu 24: print("nope")
call 13: def f(a, p, z):
line 14: if p:
line 15: print(f"{a=}")
a=0
* line 16: if a:
line 22: yield x
retu 22: yield x
call 13: def f(a, p, z):
line 14: if p:
line 15: print(f"{a=}")
a=0
* line 16: if a:
line 22: yield x
retu 22: yield x
call 13: def f(a, p, z):
line 14: if p:
line 24: print("nope")
nope
retu 24: print("nope")
call 13: def f(a, p, z):
line 14: if p:
line 24: print("nope")
nope
retu 24: print("nope")
call 13: def f(a, p, z):
line 14: if p:
line 15: print(f"{a=}")
a=1
line 16: if a:
line 17: if z:
line 21: for x in [1,2]:
line 22: yield x
retu 22: yield x
call 22: yield x
line 21: for x in [1,2]:
line 22: yield x
retu 22: yield x
call 22: yield x
line 21: for x in [1,2]:
line 22: yield x
retu 22: yield x
call 13: def f(a, p, z):
line 14: if p:
line 15: print(f"{a=}")
a=1
line 16: if a:
line 17: if z:
line 18: for x in [1,2]:
line 19: yield x
retu 19: yield x
call 19: yield x
line 18: for x in [1,2]:
line 19: yield x
retu 19: yield x
call 19: yield x
line 18: for x in [1,2]:
retu 18: for x in [1,2]:
--
components: Interpreter Core
keywords: 3.10regression
messages: 397434
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Incorrect tracing of nested if/if/for/yield
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44626>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44626] Incorrect tracing of nested if/if/for/yield
Ned Batchelder added the comment: The original reporter of the coverage.py issue says they have a simpler reproducer: https://github.com/nedbat/coveragepy/issues/1188#issuecomment-879572874 -- ___ Python tracker <https://bugs.python.org/issue44626> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44616] Incorrect tracing for "except" with variable
Ned Batchelder added the comment: Barry, is it possible you accidentally used the beta 4? I ran the test suite with a freshly built 3.10, but by mistake was still using the beta, and was surprised. Once I really got the latest build in place (Python 3.10.0b4+ (heads/3.10:47695e3c88, Jul 15 2021, 11:55:52)), I got these results: platform darwin -- Python 3.10.0b4+, pytest-6.2.4, py-1.10.0, pluggy-0.13.1 cachedir: .tox/py310/.pytest_cache rootdir: /System/Volumes/Data/root/src/foo/bug1187/flufl.lock, configfile: setup.cfg, testpaths: test, docs plugins: cov-2.12.1 collected 108 items test/test_api.py . [ 0%] test/test_lock.py ... [ 25%] docs/using.rst [100%] warnings summary = .tox/py310/lib/python3.10/site-packages/sybil/integration/pytest.py:58: 80 warnings /System/Volumes/Data/root/src/foo/bug1187/flufl.lock/.tox/py310/lib/python3.10/site-packages/sybil/integration/pytest.py:58: PytestDeprecationWarning: A private pytest class or function was used. self._request = fixtures.FixtureRequest(self) -- Docs: https://docs.pytest.org/en/stable/warnings.html -- coverage: platform darwin, python 3.10.0-beta-4 --- Name Stmts Miss Branch BrPart Cover Missing - flufl/lock/__init__.py5 0 0 0 100% flufl/lock/_lockfile.py 253 0 80 0 100% - TOTAL 258 0 80 0 100% Coverage XML written to file coverage.xml Required test coverage of 100.0% reached. Total coverage: 100.00% -- ___ Python tracker <https://bugs.python.org/issue44616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44672] Final "pass" is traced incorrectly in 3.9 (and before)
New submission from Ned Batchelder :
A simple function with a last "pass" statement gets traced incorrectly,
attributing the return to the pass instead of the actual last statement
executed:
--- 8< --
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
def wrong_loop(x):
if x:
if x:
print(4)
else:
pass
print(sys.version)
sys.settrace(trace)
wrong_loop(8)
--
On 3.9 and before, this produces:
3.9.5 (default, May 5 2021, 06:50:43)
[Clang 12.0.0 (clang-1200.0.32.29)]
call 10: def wrong_loop(x):
line 11: if x:
line 12: if x:
line 13: print(4)
4
line 15: pass
retu 15: pass
Partly I'm writing this issue to record the problem, but partly to get a
decision: will there be fixes made to 3.9 (or before) for issues like this?
--
components: Interpreter Core
messages: 397791
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Final "pass" is traced incorrectly in 3.9 (and before)
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44672>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44672] Final "pass" is traced incorrectly in 3.9 (and before)
Ned Batchelder added the comment: This is the right call. Thanks! -- ___ Python tracker <https://bugs.python.org/issue44672> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44621] Python 3.9 traces async for/else incorrectly
Ned Batchelder added the comment: @lukasz.langa, I guess this 3.9 tracing bug should also be closed as wont-fix? -- ___ Python tracker <https://bugs.python.org/issue44621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44840] Nested if/else gets phantom else trace again (3.10)
New submission from Ned Batchelder :
Note: this is very similar to https://bugs.python.org/issue42810
This was originally reported against coverage.py:
https://github.com/nedbat/coveragepy/issues/1205
---8<-
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
print(sys.version)
sys.settrace(trace)
def func():
if A:
if B:
if C:
if D:
return False
else:
return False
elif E and F:
return True
A = B = True
C = False
func()
-
This produces this trace output:
3.10.0rc1 (default, Aug 3 2021, 15:03:55) [Clang 12.0.0 (clang-1200.0.32.29)]
call 13: def func():
line 14: if A:
line 15: if B:
line 16: if C:
line 21: elif E and F:
retu 21: elif E and F:
The elif on line 21 is not executed, and should not be traced.
Also, if I change line 21 to `elif E:`, then the trace changes to:
3.10.0rc1 (default, Aug 3 2021, 15:03:55) [Clang 12.0.0 (clang-1200.0.32.29)]
call 13: def func():
line 14: if A:
line 15: if B:
line 16: if C:
line 22: return True
retu 22: return True
--
components: Interpreter Core
keywords: 3.10regression
messages: 399003
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Nested if/else gets phantom else trace again (3.10)
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue44840>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44840] Nested if/else gets phantom else trace again (3.10)
Ned Batchelder added the comment: This fix looks good, thanks. -- ___ Python tracker <https://bugs.python.org/issue44840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45020] Freeze all modules imported during startup.
Change by Ned Batchelder : -- nosy: -nedbat ___ Python tracker <https://bugs.python.org/issue45020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44450] Generator expressions trace differently on Windows than on Mac
Ned Batchelder added the comment: Looks like this is fixed with 3.10.0rc1, thanks. -- ___ Python tracker <https://bugs.python.org/issue44450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45709] 3.11 regression: tracing with-statement on exit from block
New submission from Ned Batchelder :
Python 3.11 seems to have reverted a behavior that was new in 3.10.0b1: exiting
a with-statement re-visits the with line on the way out.
--- %< bug2.py --
import linecache, sys
def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
print(sys.version)
sys.settrace(trace)
import contextlib
def f():
with contextlib.nullcontext():
1/0
f()
-
Running with 3.10 shows re-visiting the with:
$ python3.10 bug2.py
3.10.0 (default, Oct 4 2021, 17:22:29) [Clang 12.0.0 (clang-1200.0.32.29)]
call 15: def f():
line 16: with contextlib.nullcontext():
line 17: 1/0
exce 17: 1/0
line 16: with contextlib.nullcontext():
retu 17: 1/0
Traceback (most recent call last):
File "/System/Volumes/Data/root/src/foo/bug1270/bug2.py", line 19, in
f()
File "/System/Volumes/Data/root/src/foo/bug1270/bug2.py", line 17, in f
1/0
ZeroDivisionError: division by zero
3.11 does not:
$ python3.11 bug2.py
3.11.0a1 (default, Oct 6 2021, 07:21:05) [Clang 12.0.0
(clang-1200.0.32.29)]
call 15: def f():
line 16: with contextlib.nullcontext():
line 17: 1/0
exce 17: 1/0
retu 17: 1/0
Traceback (most recent call last):
File "/System/Volumes/Data/root/src/foo/bug1270/bug2.py", line 19, in
f()
^^^
File "/System/Volumes/Data/root/src/foo/bug1270/bug2.py", line 17, in f
1/0
~^~
ZeroDivisionError: division by zero
Versions before 3.10 also do not visit the with statement:
$ python3.9 bug2.py
3.9.7 (default, Sep 7 2021, 22:16:49)
[Clang 12.0.0 (clang-1200.0.32.29)]
call 15: def f():
line 16: with contextlib.nullcontext():
line 17: 1/0
exce 17: 1/0
line 17: 1/0
retu 17: 1/0
Traceback (most recent call last):
File "/System/Volumes/Data/root/src/foo/bug1270/bug2.py", line 19, in
f()
File "/System/Volumes/Data/root/src/foo/bug1270/bug2.py", line 17, in f
1/0
ZeroDivisionError: division by zero
Is this a bug in 3.11, or an intentional return to previous behavior?
(BTW: there is no 3.11regression keyword available)
--
components: Interpreter Core
messages: 405668
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: 3.11 regression: tracing with-statement on exit from block
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue45709>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45709] 3.11 regression: tracing with-statement on exit from block
Ned Batchelder added the comment: BTW, this is the coverage.py issue: https://github.com/nedbat/coveragepy/issues/1270 -- ___ Python tracker <https://bugs.python.org/issue45709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API
Ned Batchelder added the comment: I went ahead and changed the coverage.py code to this: #if PY_VERSION_HEX >= 0x030B00A0 // 3.11 moved f_lasti into an internal structure. This is totally the wrong way // to make this work, but it's all I've got until https://bugs.python.org/issue40421 // is resolved. #include #define MyFrame_lasti(f)((f)->f_frame->f_lasti * 2) #elif PY_VERSION_HEX >= 0x030A00A7 // The f_lasti field changed meaning in 3.10.0a7. It had been bytes, but // now is instructions, so we need to adjust it to use it as a byte index. #define MyFrame_lasti(f)((f)->f_lasti * 2) #else #define MyFrame_lasti(f)((f)->f_lasti) #endif If we had an API that let me distinguish between call and resume and between return and yield, I could get rid of this. -- nosy: +nedbat ___ Python tracker <https://bugs.python.org/issue40421> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45709] 3.11 regression: tracing with-statement on exit from block
Ned Batchelder added the comment: I can confirm that this fixes the problem. -- ___ Python tracker <https://bugs.python.org/issue45709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39114] Python 3.9.0a2 changed how finally/return is traced
New submission from Ned Batchelder :
The way trace function reports return-finally has changed in Python 3.9.0a2. I
don't know if this change is intentional or not.
(BTW: I want to put a 3.9regression keyword on this, but it doesn't exist.)
Consider this code:
--- 8<
import linecache, sys
def trace(frame, event, arg):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__,
lineno).rstrip()))
return trace
print(sys.version)
sys.settrace(trace)
a = []
def finally_return():
try:
return 14
finally:
a.append(16)
assert finally_return() == 14
assert a == [16]
--- 8<
(My habit is to use line numbers in the lines themselves to help keep things
straight.)
In Python 3.7 (and before), the last traces are line 14, line 16, return 16.
In Python 3.8, the last traces are line 14, line 16, line 14, return 14.
In Python 3.9a1, the traces are the same as 3.8.
In Python 3.9a2, the traces are now line 14, line 16, line 14, line 16, return
16.
This doesn't make sense to me: why does it bounce back and forth?
Full output from different versions of Python:
% /usr/local/pythonz/pythons/CPython-3.7.1/bin/python3.7 bpo.py
3.7.1 (default, Oct 20 2018, 18:25:32)
[Clang 10.0.0 (clang-1000.11.45.2)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
retu 16: a.append(16)
% /usr/local/pythonz/pythons/CPython-3.8.1/bin/python3.8 bpo.py
3.8.1 (default, Dec 19 2019, 08:38:38)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
retu 14: return 14
% /usr/local/pythonz/pythons/CPython-3.9.0a1/bin/python3.9 bpo.py
3.9.0a1 (default, Nov 20 2019, 18:52:14)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
retu 14: return 14
% /usr/local/pythonz/pythons/CPython-3.9.0a2/bin/python3.9 bpo.py
3.9.0a2 (default, Dec 19 2019, 08:42:29)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
line 16: a.append(16)
retu 16: a.append(16)
--
messages: 358771
nosy: nedbat
priority: normal
severity: normal
status: open
title: Python 3.9.0a2 changed how finally/return is traced
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39114>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
