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.or
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)\)|\.)"&qu
Change by Ned Batchelder :
--
nosy: +Mark.Shannon, nedbat
___
Python tracker
<https://bugs.python.org/issue47085>
___
___
Python-bugs-list mailing list
Unsub
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/issue47
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
Ned Batchelder added the comment:
Yes, this is fixed, thanks.
--
___
Python tracker
<https://bugs.python.org/issue46389>
___
___
Python-bugs-list mailin
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 N
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 do
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/issu
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/issue42
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/issue42
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
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/issue46
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/issue46
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
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 av
Ned Batchelder added the comment:
This fixes the problems I was seeing, thanks.
--
___
Python tracker
<https://bugs.python.org/issue46314>
___
___
Python-bug
Ned Batchelder added the comment:
Yes, thanks, this fixes it.
--
___
Python tracker
<https://bugs.python.org/issue46331>
___
___
Python-bugs-list mailin
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
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.
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/issue46
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
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, even
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/i
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
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-12
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
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 nedbatchel
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
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
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
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 ve
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
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
Ned Batchelder added the comment:
I can confirm that this fixes the problem.
--
___
Python tracker
<https://bugs.python.org/issue45709>
___
___
Python-bug
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/issue40
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/issue45
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 glob
Ned Batchelder added the comment:
Looks like this is fixed with 3.10.0rc1, thanks.
--
___
Python tracker
<https://bugs.python.org/issue44450>
___
___
Python-bug
Change by Ned Batchelder :
--
nosy: -nedbat
___
Python tracker
<https://bugs.python.org/issue45020>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Batchelder added the comment:
This fix looks good, thanks.
--
___
Python tracker
<https://bugs.python.org/issue44840>
___
___
Python-bugs-list mailin
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 we
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/issue44
Ned Batchelder added the comment:
This is the right call. Thanks!
--
___
Python tracker
<https://bugs.python.org/issue44672>
___
___
Python-bugs-list mailin
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(fram
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
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.
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
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
Ned Batchelder added the comment:
The corresponding coverage.py issue:
https://github.com/nedbat/coveragepy/issues/1158
--
___
Python tracker
<https://bugs.python.org/issue44
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
Ned Batchelder added the comment:
Based on https://github.com/nedbat/coveragepy/issues/1187, btw
--
___
Python tracker
<https://bugs.python.org/issue44
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 h
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
Ned Batchelder added the comment:
I can confirm that those two pull requests fix the problem reported here.
--
___
Python tracker
<https://bugs.python.org/issue44
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 &q
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/issue44
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
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
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(fram
Change by Ned Batchelder :
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.org/issue6>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Batchelder added the comment:
Thanks for the quick turnaround, this works!
--
___
Python tracker
<https://bugs.python.org/issue44298>
___
___
Python-bug
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&quo
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< -
imp
Ned Batchelder added the comment:
Thanks, this fixes my issue.
--
___
Python tracker
<https://bugs.python.org/issue43933>
___
___
Python-bugs-list mailin
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
<ht
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:
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:
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/issue43
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/issue43
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/issu
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
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
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 r
Change by Ned Batchelder :
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.org/issue43833>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ned Batchelder :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42823>
___
___
Pyth
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/issue42
Ned Batchelder added the comment:
This problem no longer appears with master (commit 9eb11a139f).
--
___
Python tracker
<https://bugs.python.org/issue42
Ned Batchelder added the comment:
OK, thanks. I guess the parallels between the Python frame object and the C
frame object made it easy to think I could use the fields directly. I'm
updating the coverage.py code.
--
___
Python tracker
<ht
Ned Batchelder added the comment:
This change seems like it has caused a problem. Python trace functions behave
as they did in Python 3.9, but C trace functions no longer get line numbers for
call or return events.
Running this test code:
def gen(inp):
for n in inp
Ned Batchelder added the comment:
I think I am finding more examples of the same problem, so I will just add it
here:
x = "hello"
try:
3/0
except ZeroDivisionError:
if x == 'raise':
raise ValueError() # line 6
f = 7
This shows a trace
Ned Batchelder added the comment:
This might be the same problem as #42803.
--
___
Python tracker
<https://bugs.python.org/issue42810>
___
___
Python-bugs-list m
Ned Batchelder added the comment:
This might be the same problem as #42810.
--
___
Python tracker
<https://bugs.python.org/issue42803>
___
___
Python-bugs-list m
New submission from Ned Batchelder :
(Using CPython commit 6b1ac809b9)
This program never executes line 6, but tracing it claims that it does:
a = b = x = y = z = 1
if a == 1:
if b == 1:
x = 4
else:
y = 6
else:
z = 8
assert (a, b
New submission from Ned Batchelder :
(Using CPython commit 6b1ac809b9)
This program never executes line 4, but the "if not __debug__" is partly
attributed to line 4, giving an incorrect trace:
for value in [True, False]:
if value:
if not __debug__:
Ned Batchelder added the comment:
This seems like a perspective that needs a wider audience. PEP 626 says there
will be no performance slowdown:
> Performance Implications
>
> In general, there should be no change in performance. When tracing,
> programs should run a l
Ned Batchelder added the comment:
Specifically, for jumps to jumps, what is the plan?
--
___
Python tracker
<https://bugs.python.org/issue42693>
___
___
Pytho
Ned Batchelder added the comment:
Mark, I'm trying to follow along with your ideas, but it's hard to piece
together the implications. Is there a way to have a discussion about where you
are headed?
https://github.com/python/cpython/pull/23896 "fixes" the jump to jump problems
by
Ned Batchelder added the comment:
This isn't a problem for me. I noticed it and figured I'd mention it.
--
___
Python tracker
<https://bugs.python.org/issue42
Ned Batchelder added the comment:
> According to that definition, there are still bugs in the optimizer relating
> to jumps-to-jumps. I plan to fix them
Can you say more about that? What is the bug? How will you fix it?
--
___
Python t
Change by Ned Batchelder :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue42693>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Batchelder added the comment:
Mark said:
> An optimization (CS not math) is a change to the program such that it has the
> same effect, according to the language spec, but improves some aspect of the
> behavior, such as run time or memory use.
>
> Any transformati
Ned Batchelder added the comment:
This feels like a recurring debate. I will need some time to lay out my case.
Perhaps it needs a wider audience than a bpo issue?
--
___
Python tracker
<https://bugs.python.org/issue42
Ned Batchelder added the comment:
> PEP 626 states that *all* executed code gets traced.
Yes, but reading the PEP now, it's not clear what "executed" means. Do we mean
"conceptually executed", or, "executed as compiled by the optimizing compiler"?
Ned Batchelder added the comment:
Previous versions of Python completely removed the "if 0:" statement, because
it would have no effect. The condition was checked at compile time,
effectively. It seems odd for 3.10 to a
New submission from Ned Batchelder :
(Using CPython commit c95f8bc270.)
This program has extra bytecodes:
def f():
for i in range(10):
break
return 17
The dis output is:
1 0 LOAD_CONST 0 ()
2 LOAD_CONST
New submission from Ned Batchelder :
(Using CPython commit c95f8bc270.)
This program has an "if 0:" line that becomes a NOP bytecode. It didn't used
to in Python 3.9
print(1)
if 0: # line 2
print(3)
print(4)
Using a simple trace program
(https://github.
Ned Batchelder added the comment:
(Rather: line 8 isn't executed, and so should not be traced.)
--
___
Python tracker
<https://bugs.python.org/issue42
Ned Batchelder added the comment:
I checked on this with CPython commit c95f8bc270. The code above is fixed, but
this code has a similar problem:
a, b, c = 1, 1, 1
try:
try:
a = 4/0 # ZeroDivisionError
except ValueError:
b = 6
except IndexError
Ned Batchelder added the comment:
Mark, I'm categorizing and characterizing the test failures. Here's the start
of it: https://gist.github.com/nedbat/6c5dedde9df8d2de13de8a6a39a5f112 Let me
know what other information would be useful
1 - 100 of 310 matches
Mail list logo
