[issue42887] 100000 assignments of .__sizeof__ cause a segfault on del

Mark Shannon added the comment: It won't solve the problem. Maybe make it would make it easier to avoid the segfault, but some sort of recursion/overflow check is needed. It might make the use of the trashcan cheaper, as it only need be used when stack space is running low. Ultim

[issue42951] Random and infinite loop in dealing with recursion error for "try-except "

Mark Shannon added the comment: Try setting the recursion limit to 10 or so and it should terminate. The reason ctrl-C doesn't work is that you are catching the KeyboardInterrupt. Never use a plain `except:`, use `except Exception:` -- nosy: +Mark.Sh

[issue42725] PEP 563: Should the behavior change for yield/yield from's

Mark Shannon added the comment: Draft PEP here https://github.com/markshannon/peps/blob/annotation-syntax-errors/pep-.rst Guido, would you like to be co-author as it was your idea to make these things a syntax error? -- ___ Python tracker

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

Mark Shannon added the comment: Please leave the issue open. This is a real bug. It may not be fixed right now, but that doesn't mean it won't ever be fixed. -- nosy: +Mark.Shannon ___ Python tracker <https://bugs.python.o

[issue42950] Incorrect exception behavior in handling recursive call.

Mark Shannon added the comment: If you make calls in an exception handler that is handling a RecursionError, without unwinding first, then it is likely that another RecursionError may occur. What is strange is that the second RecursionError is raised after `print(str(e))` has printed the

[issue42693] "if 0:" lines are traced; they didn't use to be

Change by Mark Shannon : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42693> ___ ___

[issue42917] Block stack size for frame objects should be dynamically sizable

Mark Shannon added the comment: Reducing the size of the frame object seems like a worthwhile goal, but what's the point in increasing the maximum block stack? -- nosy: +Mark.Shannon ___ Python tracker <https://bugs.python.org/is

[issue42925] Error trace of else inside class

Change by Mark Shannon : -- keywords: +patch pull_requests: +23047 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24222 ___ Python tracker <https://bugs.python.org/issu

[issue42925] Error trace of else inside class

Mark Shannon added the comment: It's a bug. -- assignee: -> Mark.Shannon ___ Python tracker <https://bugs.python.org/issue42925> ___ ___ Python-bugs-lis

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: I missed a "no" in the above, which somewhat changed the meaning! It should have read: "The implementation is allowed to skip any boolean test of a value, when it has *no* effect on the flow of the program and at least one test has already bee

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: The problem with using a specific syntax example, is that the optimizer doesn't work that way. It works on the CFG. Any specification needs to be phrased in terms of general control flow, as other optimizations can enable this transformation. e.g. if

[issue39934] Fatal Python error "XXX block stack overflow" when exception stacks >10

Change by Mark Shannon : -- nosy: +lukasz.langa ___ Python tracker <https://bugs.python.org/issue39934> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34705] Python 3.8 changes how returns through finally clauses are traced

Mark Shannon added the comment: In master, the sequence of events is: 1 call 2 line 3 line returning 4 line 6 line finally 6 return which is the same as 3.7. I now believe this is the correct trace, as the language spec states: When a return, break or continue statement is executed in the

[issue2506] Add mechanism to disable optimizations

Mark Shannon added the comment: In general, it is hard to define what is an optimization, and what is part of the compiler. The original request was to disable optimizations that changed observable behavior w.r.t. line numbers. All optimizations now respect line numbers, so proposed

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: Unless anyone objects, I'm going to close this issue. -- ___ Python tracker <https://bugs.python.org/issue42693> ___ ___

[issue39934] Fatal Python error "XXX block stack overflow" when exception stacks >10

Mark Shannon added the comment: Pablo, are you OK closing this without a 3.8 backport? -- ___ Python tracker <https://bugs.python.org/issue39934> ___ ___ Pytho

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Change by Mark Shannon : -- title: Is it legal to eliminate tests of a value, when that test has no effect on control flow -> Is it legal to eliminate tests of a value, when that test has no effect on control flow? ___ Python tracker <

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow

Mark Shannon added the comment: Steve, Please don't change the title of the issue. Sure, the optimizer is "inconsistent". Optimizations are applied in some cases, and not in others. That's just how compilers work. The issue here is whether the optimizer is allowed

[issue39934] Fatal Python error "XXX block stack overflow" when exception stacks >10

Mark Shannon added the comment: Does this need backporting to 3.8, or is 3.9 sufficient? -- ___ Python tracker <https://bugs.python.org/issue39934> ___ ___ Pytho

[issue42926] Split compiler into code-gen, optimizer and assembler.

New submission from Mark Shannon : Currently the compiler operates in three main passes: Code-gen Optimize Assemble The problem is that these passes use the same basic-block based CFG, leading to unnecessary coupling and inefficiencies. A basic block CFG is awkward and error-prone for the

[issue42908] Incorrect line numbers at end of try-except and with statements containing if False: pass

Change by Mark Shannon : -- pull_requests: +23036 pull_request: https://github.com/python/cpython/pull/24209 ___ Python tracker <https://bugs.python.org/issue42

[issue42908] Incorrect line numbers at end of try-except and with statements containing if False: pass

Change by Mark Shannon : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42908] Incorrect line numbers at end of try-except and with statements containing if False: pass

Mark Shannon added the comment: New changeset 3bd6035b6baf1a7d51b7cc2c6bb2c81886236b67 by Mark Shannon in branch 'master': bpo-42908: Mark cleanup code at end of try-except and with artificial (#24202) https://github.com/python/cpython/commit/3bd6035b6baf1a7d51b7cc2c6bb2c8

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: > How do we know `x` is falsey without calling `bool()` on it? We don't, but in `if x: pass`, it doesn't matter. Discounting side-effects in __bool__, the code does nothing regardless of the

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: It's clearer if you rewrite if a and b: ... as tmp = a and b if tmp: ... if a is falsey then bool(a) gets called in `tmp = a and b` and `a` is assigned to `tmp`. Then in `if tmp`, bool(a) is called again. I agree with you about it not bei

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Change by Mark Shannon : -- priority: normal -> release blocker ___ Python tracker <https://bugs.python.org/issue42899> ___ ___ Python-bugs-list mai

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: They aren't quite the same. If `a` is falsey, and bool(a) has a side-effect, then that side-effect should occur twice in: if a and b: ... but only once in if a: if b: ... It gets more interesting (silly), if `a.__bool__()` alternated be

[issue42908] Incorrect line numbers at end of try-except and with statements containing if False: pass

Change by Mark Shannon : -- keywords: +patch pull_requests: +23027 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24202 ___ Python tracker <https://bugs.python.org/issu

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: The question still stands. Is converting `if x: pass` to `pass` legal? And, if it is not, is converting if a and b: body to if a: if b: body a legal transformation? (ignoring line numbers) If the first transformation is not allowed but

[issue42908] Incorrect line numbers at end of try-except and with statements containing if False: pass

New submission from Mark Shannon : The following examples produce incorrect line numbers, due to cleanup code not being marked as artificial def f(): try: if False: pass except: X def g(a): with a: if False: pass

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: The issue here is: Is it legal to convert if x: pass into pass ? The explicit effect of the code is unchanged, BUT the implicit effect (of calling x.__bool__) is changed. The examples Serhiy gives are similar. If `bool(a)` evaluates to False, then

[issue42899] Possible regression introduced by bpo-42615

Change by Mark Shannon : -- assignee: -> Mark.Shannon ___ Python tracker <https://bugs.python.org/issue42899> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue42873] Exponential time and space requirements for compilation of nested try/finally blocks

Mark Shannon added the comment: I don't see what the problem is here. People just don't write code like that, at least not if they do code review ;) And even, in the *extremely* rare case that they do, the code executes correctly and reasonably quickly. It just uses a bit of ex

[issue42725] PEP 563: Should the behavior change for yield/yield from's

Mark Shannon added the comment: What's the process for making a decision on whether to make 'yield' in an annotation a syntax error? As a language change it should have a PEP, IMO. The PEP will be short, and shouldn't need a long-winded acceptance process. I just thin

[issue42823] Incorrect frame.f_lineno when frame.f_trace is set

Change by Mark Shannon : -- pull_requests: +22978 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/24150 ___ Python tracker <https://bugs.python.org/issu

[issue42823] Incorrect frame.f_lineno when frame.f_trace is set

Mark Shannon added the comment: It looks like you are accessing the c field "f_lineno" directly. That was never guaranteed to work, it just happened to. You should use PyFrame_GetLineNumber() If "f_lineno" is up to date, then it will be almost efficient as the direc

[issue42837] Symbol table incorrectly identifies code as a generator, when 'yield' occurs in an annotation

Mark Shannon added the comment: OK, I won't merge anything yet. -- ___ Python tracker <https://bugs.python.org/issue42837> ___ ___ Python-bugs-list m

[issue42837] Symbol table incorrectly identifies code as a generator, when 'yield' occurs in an annotation

Mark Shannon added the comment: The aim is to change the behavior of the symbol table to match the compiler. The behavior has already changed at module scope. Python 3.9.0+ >>> x:(yield None) File "", line 1 SyntaxError: 'yield' outside function >>>

[issue42837] Symbol table incorrectly identifies code as a generator, when 'yield' occurs in an annotation

Change by Mark Shannon : -- keywords: +patch pull_requests: +22967 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/24138 ___ Python tracker <https://bugs.python.org/issu

[issue42725] PEP 563: Should the behavior change for yield/yield from's

Mark Shannon added the comment: I've also opened #42837 which is about fixing the symbol table, so that it is correct w.r.t. to current behavior. I'd like to fix it ASAP as the compiler should be able to rely on the symbol table being correct. Of course, once we have decide

[issue42837] Symbol table incorrectly identifies code as a generator, when 'yield' occurs in an annotation

Mark Shannon added the comment: No this is not a duplicate. This is about making the symbol table correct for current semantics. #42725 is about changing the behavior -- resolution: duplicate -> status: closed -> open superseder: PEP 563: Should the behavior change for yield

[issue42837] Symbol table incorrectly identifies code as a generator, when 'yield' occurs in an annotation

New submission from Mark Shannon : This is an internal inconsistency. I have not identified any surface level bugs, but it is a trap for future compiler work. -- assignee: Mark.Shannon messages: 384479 nosy: Mark.Shannon, larry priority: normal severity: normal status: open title

[issue42823] Incorrect frame.f_lineno when frame.f_trace is set

Change by Mark Shannon : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42823] Incorrect frame.f_lineno when frame.f_trace is set

Mark Shannon added the comment: New changeset ee9f98d9f4b881ee15868a836a2b99271df1bc0e by Mark Shannon in branch 'master': bpo-42823: Fix frame lineno when frame.f_trace is set (GH-24099) https://github.com/python/cpython/commit/ee9f98d9f4b881ee15868a836a2b99

[issue41463] Avoid duplicating jump information from opcode.py in compile.c

Mark Shannon added the comment: I don't think we want to backport it -- stage: patch review -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.

[issue42810] Nested if/else gets phantom else trace (3.10)

Change by Mark Shannon : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42803] Traced line number is wrong for "if not __debug__"

Change by Mark Shannon : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42803> ___

[issue42823] Incorrect frame.f_lineno when frame.f_trace is set

Change by Mark Shannon : -- keywords: +patch pull_requests: +22930 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24099 ___ Python tracker <https://bugs.python.org/issu

[issue42810] Nested if/else gets phantom else trace (3.10)

Mark Shannon added the comment: New changeset 127dde591686816e379d1add015304e6b9fb6954 by Mark Shannon in branch 'master': bpo-42810: Mark jumps at end of if and try statements as artificial. (GH-24091) https://github.com/python/cpython/commit/127dde591686816e379d1add015304

[issue42823] Incorrect frame.f_lineno when frame.f_trace is set

New submission from Mark Shannon : The logic for frame.f_lineno assumes that the internal C field will be updated when f_trace is set, but that is incorrect. Consequently, the following code import sys def print_line(): print(sys._getframe(1).f_lineno) def test(): print_line

[issue42739] Crash when try to disassemble bogus code object

Mark Shannon added the comment: dis is able to handle code with no line numbers. >>> def f(): pass ... >>> co = f.__code__.replace(co_linetable=b'\xff') >>> list(co.co_lines()) [] >>> import dis >>> dis.dis(co) 0 LOAD_CON

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

Change by Mark Shannon : -- pull_requests: +22923 pull_request: https://github.com/python/cpython/pull/24094 ___ Python tracker <https://bugs.python.org/issue42

[issue42810] Nested if/else gets phantom else trace (3.10)

Change by Mark Shannon : -- keywords: +patch pull_requests: +22922 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24091 ___ Python tracker <https://bugs.python.org/issu

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

Mark Shannon added the comment: New changeset 28b75c80dcc1e17ed3ac1c69362bf8dc164b760a by Mark Shannon in branch 'master': bpo-42246: Don't eliminate jumps to jumps, if it will break PEP 626. (GH-23896) https://github.com/python/cpython/commit/28b75c80dcc1e17ed3ac1c693

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: I'll briefly answer the above questions, but we could we close this issue? If there are specific issues regarding PEP 626, please make a new issue. Feel free to +nosy me on those issues. I intend to review all the recent changes to the compiler in th

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: There isn't much of a plan. https://github.com/python/cpython/pull/23896 makes the optimizer respect PEP 626 w.r.t. jumps-to-jumps. >From the point of view of optimization, there is nothing special about >jumps-to-jumps. Any optimization that off

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: Are you interested in the "what" or the "how"? The "what": PEP 626 defines what CPython must do in terms of tracing lines executed. The "how": Obviously, we want to execute Python as efficiently as possible

[issue2506] Add mechanism to disable optimizations

Mark Shannon added the comment: I think this can finally be closed. A mere 12 years after it was opened :) PEP 626 specifies what the correct behavior is, regardless of whether optimizations are turned on or off, so there is no point in a no-optimize option. The compiler is fast enough that

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: The fix, which explains the bug: https://github.com/python/cpython/pull/23896 -- ___ Python tracker <https://bugs.python.org/issue42

[issue42696] Duplicated unused bytecodes at end of function

Mark Shannon added the comment: In what way is it "kludgy"? There is a mathematical theorem that states that generated code will be imperfect, so we will have to live with that :) https://en.wikipedia.org/wiki/Full_employment_theorem 3.10a produces more efficient bytecode than

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

Change by Mark Shannon : -- pull_requests: +22751 pull_request: https://github.com/python/cpython/pull/23896 ___ Python tracker <https://bugs.python.org/issue42

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: Ned, I agree that up until 3.9, it is wasn't that simple. But from 3.10 onward, it should be that simple. That's the point of PEP 626. If a transformation changes observable behavior within the scope of language specification, then it is not an op

[issue42719] Eliminate NOPs in the assembler, by emitting zero-width entries in the line number table

New submission from Mark Shannon : This will require a change to the internal line number table format. PEP 626 requires all lines are traced, which makes handling of 'continue' and other jump-to-jumps inefficient if spread across multiple lines. In 3.9 many jump-to-jumps were

[issue42718] Allow zero-width entries in code.co_lines()

Change by Mark Shannon : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42718] Allow zero-width entries in code.co_lines()

New submission from Mark Shannon : While the impact of making `if 0` and `while True` appear when tracing can be mitigated, the impact of `continue` is more of a concern. The following loop: while True: if test: continue rest PEP 626 requires that the `continue` is traced

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: What is the problem with NOPs? If there are performance regressions in real code, then that needs to be addressed. If only in a few toy examples, then that is (IMO) a price worth paying for predictable debugging and profiling. Raymond: Effectively it does

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: You should never have to disable optimizations. Let's be clear about what an optimization is. 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 beh

[issue42634] Incorrect line number in bytecode for try-except-finally

Mark Shannon added the comment: New changeset f2dbfd7e20431f0bcf2b655aa876afec7fe03c6f by Mark Shannon in branch 'master': bpo-42634: Mark reraise after except blocks as artificial. (GH-23877) https://github.com/python/cpython/commit/f2dbfd7e20431f0bcf2b655aa876af

[issue42696] Duplicated unused bytecodes at end of function

Mark Shannon added the comment: Our reachability analysis is correct (in this case at least). There is no unreachable code here. In theory we could merge the two basic blocks at the end, but searching for identical blocks and merging them is potentially quite expensive (and fiddly). What

[issue42634] Incorrect line number in bytecode for try-except-finally

Change by Mark Shannon : -- pull_requests: +22740 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/23877 ___ Python tracker <https://bugs.python.org/issu

[issue42696] Duplicated unused bytecodes at end of function

Mark Shannon added the comment: My guess is that we are changing the CFG after computing reachability leaving unreachable blocks marked as reachable. -- assignee: -> Mark.Shannon ___ Python tracker <https://bugs.python.org/issu

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: But why remove it? It is in the source code. Do we want tracing and profiling to depend on what transformations the optimizer does or does not make? What lines are to be traced here? What is the last line executed? def no_code(): if 0: some_code

[issue42634] Incorrect line number in bytecode for try-except-finally

Change by Mark Shannon : -- resolution: fixed -> ___ Python tracker <https://bugs.python.org/issue42634> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: Yes, this is change is deliberate. PEP 626 states that *all* executed code gets traced. Occasionally that will result in NOPs in the code, that are necessary for correctness, but cannot be removed by the optimizer. Is this a problem in practice? In fact this

[issue42645] break/continue or return in finally block occurs twice in trace.

Change by Mark Shannon : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

Mark Shannon added the comment: New changeset bf353f3c2d937772a8cf30b15fd8eb7b82665ccb by Mark Shannon in branch 'master': bpo-42246: Make sure that `f_lasti`, and thus `f_lineno`, is set correctly after raising or reraising an exception (GH-23803) https://github.com/python/cpyt

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

Change by Mark Shannon : -- pull_requests: +22663 pull_request: https://github.com/python/cpython/pull/23803 ___ Python tracker <https://bugs.python.org/issue42

[issue42645] break/continue or return in finally block occurs twice in trace.

Mark Shannon added the comment: New changeset 5274b682bc93a04da8a69742528ac7f64633a96e by Mark Shannon in branch 'master': bpo-42645: Make sure that return/break/continue are only traced once when exiting via a finally block. (GH-23780) https://github.com/python/cpyt

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

Mark Shannon added the comment: https://github.com/python/cpython/pull/23780 fixes the finally handling. The if-break case was fixed by earlier changes. -- ___ Python tracker <https://bugs.python.org/issue42

[issue42615] Redundant jump instructions due to deleted unreachable bytecode blocks

Mark Shannon added the comment: New changeset c71581c7a4192e6ba9a79eccc583aaadab300efa by Om G in branch 'master': bpo-42615: Delete redundant jump instructions that only bypass empty blocks (GH-23733) https://github.com/python/cpython/commit/c71581c7a4192e6ba9a79eccc583aa

[issue42645] break/continue or return in finally block occurs twice in trace.

Change by Mark Shannon : -- keywords: +patch pull_requests: +22638 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23780 ___ Python tracker <https://bugs.python.org/issu

[issue42645] break/continue or return in finally block occurs twice in trace.

New submission from Mark Shannon : This function def f(): try: return 2 finally: 4 would generate a try of [1, 2, 4, 2]. It should generate [1, 2, 4] and not trace the return twice. -- assignee: Mark.Shannon messages: 383044 nosy: Mark.Shannon, nedbat

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

Mark Shannon added the comment: New changeset 8473cf89bdbf2cb292b39c972db540504669b9cd by Mark Shannon in branch 'master': bpo-42246: Remove DO_NOT_EMIT_BYTECODE macros, so that while loops and if statements conform to PEP 626. (GH-23743) https://github.com/python/cpyt

[issue42635] Incorrect line number in bytecode for nested loops

Change by Mark Shannon : -- resolution: -> fixed stage: patch review -> needs patch status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42634] Incorrect line number in bytecode for try-except-finally

Change by Mark Shannon : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

Mark Shannon added the comment: Thanks Ned, that's really helpful. I'll go through those points: Code after break/continue is no longer compiled. Expected First line number of modules Expected Except clause when no exception https://bugs.python.org/issue42634 Double l

[issue42635] Incorrect line number in bytecode for nested loops

Mark Shannon added the comment: New changeset f5e97b72fecff9b9ced35704ec5e6cad29e2825d by Mark Shannon in branch 'master': bpo-42635: Mark JUMP_ABSOLUTE at end of 'for' loop as artificial to avoid spurious line events. (GH-23761) https://github.com/p

[issue42635] Incorrect line number in bytecode for nested loops

Change by Mark Shannon : -- keywords: +patch pull_requests: +22617 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23761 ___ Python tracker <https://bugs.python.org/issu

[issue42635] Incorrect line number in bytecode for nested loops

New submission from Mark Shannon : The following code, when traced, produces a spurious line events at the end of the inner loop. def dloop(): for i in range(3): for j in range(3): a = i + j assert a == 4 Bug reported by Ned Batchelder https://gist.github.com

[issue42634] Incorrect line number in bytecode for try-except-finally

Change by Mark Shannon : -- keywords: +patch pull_requests: +22616 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23760 ___ Python tracker <https://bugs.python.org/issu

[issue42634] Incorrect line number in bytecode for try-except-finally

New submission from Mark Shannon : The following code, when traced, produces a spurious line event for line 5: a, b, c = 1, 1, 1 try: a = 3 except: b = 5 finally: c = 7 assert a == 3 and b == 1 and c == 7 Bug reported by Ned Batchelder https://gist.github.com/nedbat

[issue42246] Implement PEP 626

Mark Shannon added the comment: Ned, What are the failures? I'd like to take a look, to see if things are as expected, and if there are any tests we can add to CPython. -- ___ Python tracker <https://bugs.python.org/is

[issue42246] Implement PEP 626

Change by Mark Shannon : -- pull_requests: +22601 pull_request: https://github.com/python/cpython/pull/23743 ___ Python tracker <https://bugs.python.org/issue42

[issue40747] sysconfig.get_config_var("py_version_nodot") should return 3_10

Mark Shannon added the comment: What's blocking this? It is a real pain not to be able to install packages for 3.10. I don't much care what the format is, but since there seems to be some difficulty in changing it, why not leave the output as `310`? It isn't ambiguous, as lon

[issue42373] PEP 626 does not specify behavior of tracing for keywords.

Change by Mark Shannon : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42373> ___

[issue42562] dis failed to parse function that has only annotations

Mark Shannon added the comment: Thanks Yurii -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42246] Implement PEP 626

Mark Shannon added the comment: New changeset eaccc12aa986f92ea05f3f0a63cedbff78dd67f1 by Mark Shannon in branch 'master': bpo-42246: Don't forget the entry block when ensuring that all exits have a line number (GH-23636) https://github.com/python

[issue42562] dis failed to parse function that has only annotations

Mark Shannon added the comment: New changeset f24b8101a01fa98b1e3ec042ba896aeb4c24d4bc by Yurii Karabas in branch 'master': bpo-42562: Fix issue when dis failed to parse function that has no line numbers (GH-23632) https://github.com/python/cpyt

[issue42562] dis failed to parse function that has only annotations

Mark Shannon added the comment: There are two issues here. 1. The compiler is not following PEP 626 for functions with no executable code 2. dis is not robust in the case that there are no line numbers. I want to fix 1. first, then 2

[issue42246] Implement PEP 626

Change by Mark Shannon : -- pull_requests: +22504 pull_request: https://github.com/python/cpython/pull/23636 ___ Python tracker <https://bugs.python.org/issue42

<    3   4   5   6   7   8   9   10   11   12   >