Ned Batchelder added the comment:
Thanks, that fixes the original case in this issue.
Here is another problem which seems related enough to append here instead of
opening a new issue:
--- 8<
import linecache, sys
def trace(frame, ev
Ned Batchelder added the comment:
BTW: this is not a regression in your fix. 3.9a2 behaved this way also.
--
___
Python tracker
<https://bugs.python.org/issue39
New submission from Ned Batchelder :
3.9.0a2 changed how the final iteration of "async for" is traced. The body of
the loop is traced when the body is not executed. Standard "for" loops don't
show the same effect.
In the output below, notice that 3.9.0a2 and 3.
New submission from Ned Batchelder :
I know this is not allowed:
>>> ((a, b, c) := (1, 2, 3))
File "", line 1
SyntaxError: cannot use named assignment with tuple
But what is "named assignment", and why is this SyntaxError talking about it?
Shouldn&#x
Change by Ned Batchelder :
--
keywords: +patch
pull_requests: +17210
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/1
___
Python tracker
<https://bugs.python.org/issu
Ned Batchelder added the comment:
I see that you are right, the bytecode is the same in 3.8 and 3.9.
Nevertheless, the trace has definitely changed. Using the same program from
the top of the issue, here are the ends of the traces for a number of Python
versions. The extra trace of line
Ned Batchelder added the comment:
Pablo, thanks, but that PR does not fix this problem.
I'm a little confused: there's a program in this issue to demonstrate the
problem. Can I do something to make it easier for you to use?
--
___
Pyth
Ned Batchelder added the comment:
What would it take to get this merged?
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.org/issue16379>
___
___
Pytho
Change by Ned Batchelder :
___
Python tracker
<https://bugs.python.org/issue16379>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/o
Change by Ned Batchelder :
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.org/issue39318>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ned Batchelder :
--
keywords: +patch
pull_requests: +17389
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17985
___
Python tracker
<https://bugs.python.org/issu
Ned Batchelder added the comment:
This change has caused a problem for coverage.py. The full details are here:
https://github.com/nedbat/coveragepy/issues/988#issuecomment-626926513
Coverage.py combines fnmatch-produced regexes by joining them with pipes into
one larger regex. The \ group
Ned Batchelder added the comment:
Wow, thanks Tim. To be honest, I was coming around to your original point of
view that it was too much to promise that these regexes could be combined the
way I'm doing it. If we have to undo this latest change, I can live wi
Ned Batchelder added the comment:
Mark, BTW: I have run the coverage.py test suite on 3.10.0a3, and as expected
there are failures. I haven't dug into it yet to see what looks expected and
what does not. I also see there are still changes happening on master, so I'm
not su
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
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:
a
Ned Batchelder added the comment:
(Rather: line 8 isn't executed, and so should not be traced.)
--
___
Python tracker
<https://bugs.python.org/is
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://gi
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
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 add
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:
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:
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 transformation 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:
> 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
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.o
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 pr
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:
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 little f
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__:
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
Ned Batchelder added the comment:
This might be the same problem as #42810.
--
___
Python tracker
<https://bugs.python.org/issue42803>
___
___
Python-bugs-list m
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:
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 show
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:
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
&
Ned Batchelder added the comment:
This problem no longer appears with master (commit 9eb11a139f).
--
___
Python tracker
<https://bugs.python.org/issue42
New submission from Ned Batchelder :
Coverage.py bug reports https://github.com/nedbat/coveragepy/issues/1022 and
https://github.com/nedbat/coveragepy/issues/959 demonstrate the same Python
code, with the same disassembly, executing differently.
In
https://discuss.python.org/t/same-python
Ned Batchelder added the comment:
If there is any doubt that this affects people, it was reported *again* against
coverage.py today: https://github.com/nedbat/coveragepy/issues/1025
--
___
Python tracker
<https://bugs.python.org/issue2
New submission from Ned Batchelder :
The "Other Resources" section lists these resources:
Guido's Essays: out of date, the first is about 2.2, by the fifth, we're into
Python 1.5.
New-style Classes: this means "new" as of 2.2, and the linked page begins,
&qu
New submission from Ned Batchelder :
CPython 3.8.0b2 behaves differently than previous releases: it no longer
optimizes away "if 0:" branches. This is something that has been done since at
least 2.4. It was done in 3.8.0b1, but no longer is.
Was this a purposeful change? Why? It
Ned Batchelder added the comment:
BTW, the same regression applies to "if not __debug__:" . Python3.8.0b1
optimized these away, but b2 does not. That optimization was new in 3.7.0a4
--
___
Python tracker
<https://bugs.python.o
Ned Batchelder added the comment:
Since this was backported to 3.7 but not yet released, I'm adding 3.7regression.
--
keywords: +3.7regression
___
Python tracker
<https://bugs.python.org/is
Ned Batchelder added the comment:
The real-word implications from my world are this: if your code has "if 0:"
clauses in it, and you measure its coverage, then because the lines have not
been optimized away, coverage.py will think the lines are a possible execution
path, a
Ned Batchelder added the comment:
I don't know what you mean by, "it should not be rely upon." Are you saying
that in 3.8 you want to keep the lines in the compiled bytecode? Do you
understand the implications for cover
Ned Batchelder added the comment:
I can see the logic of the argument that says the code exists, and should be
measured. But this is changing behavior that has been in place for at least 15
years.
Before this change, code could have had an unreported SyntaxError, but it was
code that was
Ned Batchelder added the comment:
To add to the confusion, the treatment of "if __debug__:" and "if not
__debug__:" is now asymmetric:
Here is debug.py:
import dis
import sys
print(sys.version)
def f():
if __debug__:
print("debug")
else:
Change by Ned Batchelder :
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.org/issue33944>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Batchelder added the comment:
Whoever takes this up next: let me know if I can help.
--
___
Python tracker
<http://bugs.python.org/issue11978>
___
___
Pytho
Changes by Ned Batchelder :
--
nosy: +nedbat
title: Tracis CI coverage job fails on Python 3.6 -> Travis CI coverage job
fails on Python 3.6
___
Python tracker
<http://bugs.python.org/issu
Ned Batchelder added the comment:
I happen to use xml.dom.minidom, though I didn't mean this to be, "fix Ned's
personal problem" :)
--
___
Python tracker
<https://bug
Ned Batchelder added the comment:
FWIW, Yury started a pull request: https://github.com/python/cpython/pull/9693
--
keywords: -patch
___
Python tracker
<https://bugs.python.org/issue2
New submission from Ned Batchelder:
3.6.1rc1 adds the current directory to sys.path when running a subdirectory's
__main__.py
Previous versions, including 3.6.0, did not. Is this intentional?
$ pwd
/Users/ned/foo
$ cat main361/__main__.py
import pprint, sys
pprint.pprint(sys.path)
$ for v
Ned Batchelder added the comment:
BTW, I don't know if this is relevant, but PyPy has added the current directory
in this situation for a long time.
--
___
Python tracker
<http://bugs.python.org/is
Ned Batchelder added the comment:
I don't have a specific problem that it causes. It's just a difference from any
previous CPython version.
About the PyPy thing: it has always behaved this way:
$ for ver in 4.0.1 5.1.1 5.4.0 5.6.0; do
py=/usr/local/pythonz/pythons/PyPy-$ver/bin/py
Changes by Ned Batchelder :
--
nosy: +nedbat
___
Python tracker
<http://bugs.python.org/issue29642>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Batchelder added the comment:
I'm a bit mystified why people are still opposed to providing sorting control,
even after people are resorting to "hack work-arounds." The (two) pull
requests that provide the control are simple, easy to understand, and easy to
test.
Ray
Ned Batchelder added the comment:
Thanks for the suggestion. My problem has already been fixed with my own hack
workaround. Your idea is a good one to leave here so that other frustrated
users will have code to copy for their hack workaround
New submission from Ned Batchelder :
In Python 3.7.3, having a trace function in effect while mock is imported
causes isinstance to be wrong for MagicMocks. I know, this sounds unlikely...
$ cat traced_sscce.py
# sscce.py
import sys
def trace(frame, event, arg):
return trace
if len
Ned Batchelder added the comment:
This also affects Python 3.8.0a3
--
___
Python tracker
<https://bugs.python.org/issue36593>
___
___
Python-bugs-list mailin
Change by Ned Batchelder :
--
keywords: +3.7regression
___
Python tracker
<https://bugs.python.org/issue36593>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Batchelder added the comment:
BTW, this started as a bug against coverage.py:
https://github.com/nedbat/coveragepy/issues/795
There are some more details there, including the fact that it must be a Python
trace function; a C trace function seems not to cause the problem
Ned Batchelder added the comment:
3.8.0a3 is out, and the What's New still doesn't mention this work yet.
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.o
Ned Batchelder added the comment:
Maybe we could update the What's New quickly now, and then get the longer more
complex docs done later? People have been asking if this feature is in 3.8
because they don't see it mentioned.
--
New submission from Ned Batchelder :
The math and cmath modules say this in their docs: "This module is always
available." This lead a beginner to believe they didn't need to be imported.
Nearly the entire standard library is always available in this sense (they can
be i
Change by Ned Batchelder :
--
keywords: +patch
pull_requests: +13207
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36908>
___
___
Py
Ned Batchelder added the comment:
If we want to keep it, how about "it can always be imported."? Though I still
wonder whether this is worth it. Are we going to annotate all of the
always-available modules with this notation?
--
Ned Batchelder added the comment:
Looks like these modules describe themselves as always available: _thread, sys,
threading, time.
Notice that the built-ins are also described as "always available", which is
the meaning we're trying to move math away from (you can u
Ned Batchelder added the comment:
There are hundreds of modules that are always importable. The majority of the
standard library is always importable. More useful would be to annotate those
modules that might not be importable, with a reason why
New submission from Ned Batchelder :
The issue that I reported in https://bugs.python.org/issue29723 is now
affecting 3.5.4:
```
$ pwd
/Users/ned/foo
$ tree syspathmain
syspathmain
└── __main__.py
0 directories, 1 file
$ cat syspathmain/__main__.py
import sys
print("-" *
Ned Batchelder added the comment:
(For clarity)
The problem is that 3.5.4 adds the current directory to sys.path when running a
subdirectory's __main__.py. No other version of Python does this.
--
___
Python tracker
<https://bugs.py
Ned Batchelder added the comment:
I can confirm that 3.5.5rc1 fixes the problem I had.
--
___
Python tracker
<https://bugs.python.org/issue32551>
___
___
Pytho
Ned Batchelder added the comment:
Should this get an entry in the What's New?
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.org/issue32305>
___
___
Ned Batchelder added the comment:
As is usual for me, I am here because some coverage.py code broke due to this
change. A diff between b1 and b2 found me the code change (thanks for the
comment, btw!), but a What's New doesn't seem ou
New submission from Ned Batchelder :
"pydoc coverage" worked with 3.7b2, but fails with a surprising
ModuleNotFoundError for configparser with b3. The configparser is importable
in the Python interpreter. I tried with -v to what imports were attempted, and
configparser isn't
Ned Batchelder added the comment:
Turns out it's even simpler:
$ pydoc itertools
No module named 'ast'
# !!!
--
___
Python tracker
<https://bugs.pyt
Ned Batchelder added the comment:
Oh, sorry, I forgot that import attempts aren't shown until -vv
--
___
Python tracker
<https://bugs.python.org/is
Ned Batchelder added the comment:
PR 6273 is mentioned, but I think 6573 is the correct number.
--
___
Python tracker
<https://bugs.python.org/issue16
Ned Batchelder added the comment:
Folding constants won't affect control flow. The important thing here is to
disable optimizing away jumps to jumps.
--
___
Python tracker
<https://bugs.python.org/i
Ned Batchelder added the comment:
Serhiy: thanks for the fuller story about the optimizations in place now. I'll
repeat my earlier plea: providing a way to disable optimization is beneficial
for tooling like coverage.py, and also for helping us to ensure that the
optimizer is wo
New submission from Ned Batchelder :
I'm not sure if this is a regression or an intentional change. I know that the
behavior has changed.
If a function has a docstring but no other body, Python 3.7b5 assigns the line
number of the docstring to the implicit "return None". Pr
Ned Batchelder added the comment:
Coverage.py is registering a handler to save data before the program ends. The
execv call is not in the coverage.py code, it's in the program that coverage.py
is running.
--
___
Python tracker
&
Ned Batchelder added the comment:
The trace module doesn't get much use. Have you tried using coverage.py?
https://pypi.org/project/coverage/
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.org/is
New submission from Ned Batchelder :
When a return statement also executes a finally clause, the sequence of lines
reported to the trace function is different in 3.8 than it has been before 3.8:
$ cat finally_trace.py
def return_from_finally():
try:
print("retu
Ned Batchelder added the comment:
This affects coverage.py, as reported in this bug:
https://github.com/nedbat/coveragepy/issues/707
--
___
Python tracker
<https://bugs.python.org/issue34
Ned Batchelder added the comment:
I can't tell if you think this is something that should be fixed, or not?
(Also, I'm not getting email notifications from bpo, sorry for the delay).
--
___
Python tracker
<https://bugs.python.o
Change by Ned Batchelder :
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.org/issue2771>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Batchelder added the comment:
A test comment from nedbat
--
___
Python tracker
<https://bugs.python.org/issue2771>
___
___
Python-bugs-list mailin
Ned Batchelder added the comment:
Also a test.
--
___
Python tracker
<https://bugs.python.org/issue2771>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ned Batchelder :
When decorating a function, the sequence of lines reported to the trace
function is different in Python3.8 than with previous versions
$ cat -n decorator.py
1 def decorator(f):
2 return f
3
4 def f():
5 @decorator
Ned Batchelder added the comment:
The other drawback is changing how the trace function is notified in a few
scenarios.
--
nosy: +nedbat
___
Python tracker
<https://bugs.python.org/issue12
Ned Batchelder added the comment:
Are we sure this is the behavior we want? Now when I step through your code in
the debugger, it will show me line 2, then 3, then 4, then 2 again.
I can see the appeal for a multiline assignment statement, but for stacked
decorators it just seems wrong
Ned Batchelder added the comment:
Yes, I agree that the assignment statement behavior is fine. The stacked
decorator behavior is not.
I understand that under the hood the two cases are very similar, but the syntax
is different. Jumping back to the first decorator makes it look like the
New submission from Ned Batchelder :
Looks like the optimizer is getting more aggressive. Line 2 (the constant
while) no longer even appears in the bytecode:
$ cat -n whiletrue.py
1 a = 1
2 while 1:
3 print(a)
4 b = 4
$ python3.7 -m dis < whiletrue.py
Change by Ned Batchelder :
--
nosy: +benjamin.peterson, vstinner
___
Python tracker
<https://bugs.python.org/issue34888>
___
___
Python-bugs-list mailin
Ned Batchelder added the comment:
Yury, thanks. I haven't read the code in depth. I assume there is some place
that notices that the while condition is a constant, and therefore doesn't need
to be explicitly evaluated? That test can be dis
Ned Batchelder added the comment:
This is the --trace output for some stacked decorators:
$ cat -n /tmp/decdec.py
1 def decorator1(f):
2 return f
3
4 def decorator2(f):
5 return f
6
7 def decorator3(f):
8 return f
9
10
Ned Batchelder added the comment:
Thanks, the fix looks good to me.
I made a comparison of some decorator tracing to check it out:
https://gist.github.com/nedbat/d603a34136299f0c0b8e442fccadeb7d
TBH, the first time I tried it, something seemed wrong, but I can't see it now,
so
Ned Batchelder added the comment:
Another option is to make clear in the docs that the command line does not
accept regular expressions, but only literal module names, and raise an error
if a non-importable name (for example with asterisks in it) is specified.
And while we are here: the
Ned Batchelder added the comment:
This seems like a confusion of two things: identifiers are lexical elements of
the language. Attributes are not limited to identifiers.
We could add to the docs for setattr: "The attribute name does not have to be a
valid identifier." I don&#
101 - 200 of 311 matches
Mail list logo
