[issue462937] continue inside try confuses while loop

Change by admin : -- github: None -> 35206 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue406287] last try: INSTALL_SCRIPT

Change by admin : -- github: None -> 34076 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue227098] Explanation of try/else in Lang Ref is flawed

Change by admin : -- github: None -> 33646 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue403048] Generate simple JUMP_FORWARD for 'break' outside 'try'

Change by admin : -- github: None -> 33647 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue403045] Tim's proposed new text for 'else' in try/except/else

Change by admin : -- github: None -> 33644 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue402989] Allow 'continue' inside 'try' clause

Change by admin : -- github: None -> 33628 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401071] whichdb.py: add missing "try:" statement

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue210830] "continue" inside "try" (PR#177)

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401071] whichdb.py: add missing "try:" statement

Change by admin : -- github: None -> 32882 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue210830] "continue" inside "try" (PR#177)

Change by admin : -- github: None -> 32831 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46458] Optimise try-except code generation for the happy path

Irit Katriel added the comment: Re next steps, see https://github.com/faster-cpython/ideas/issues/226#issuecomment-1024875216. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue46458] Optimise try-except code generation for the happy path

Irit Katriel added the comment: New changeset 36f538c8092eeb3d5b8bc9df0ae7cc348f08a865 by Irit Katriel in branch 'main': bpo-46458: Add tests for context of exception in finally block (GH-30986) https://github.com/python/cpython/commit/36f538c8092eeb3d5b8bc9df0ae7cc348f08a865 --

[issue46458] Optimise try-except code generation for the happy path

Change by Irit Katriel : -- pull_requests: -29165 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46458] Optimise try-except code generation for the happy path

Change by Irit Katriel : -- pull_requests: +29165 pull_request: https://github.com/python/cpython/pull/30986 ___ Python tracker ___

[issue46458] Optimise try-except code generation for the happy path

Irit Katriel added the comment: New changeset 3d2ce3471646704ebd5252f4b20f065f139a53b1 by Irit Katriel in branch 'main': bpo-46458: emit code for else of a try block immediately after the try body (GH-30751) https://github.com/python/cpython/commit/3d2ce3471646704ebd5252f4b20f065f139a53b1

[issue46458] Optimise try-except code generation for the happy path

Irit Katriel added the comment: See also the discussion on https://github.com/faster-cpython/ideas/issues/226. -- ___ Python tracker ___

[issue46458] Optimise try-except code generation for the happy path

Change by Irit Katriel : -- keywords: +patch pull_requests: +28938 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30751 ___ Python tracker ___

[issue46458] Optimise try-except code generation for the happy path

New submission from Irit Katriel : The compiler emits code for try-except-else-finally in the order in which it appears in the source, but it could probably produce faster code if it optimizes for the no-exception path. -- assignee: iritkatriel components: Interpreter Core messages

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Serhiy Storchaka added the comment: New changeset bee660e46ae2a051400177dcd758d95b5b4a6fcc by Miss Islington (bot) in branch '3.9': [3.9] Remove a NEWS entry for bpo-45878 (GH-30258) (GH-30260) https://github.com/python/cpython/commit/bee660e46ae2a051400177dcd758d95b5b4a6fcc --

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Serhiy Storchaka added the comment: New changeset 1fb7c61ca76c6fbff4d90b272e34e92bc2c7d729 by Serhiy Storchaka in branch 'main': Remove a NEWS entry for bpo-45878 (GH-30259) https://github.com/python/cpython/commit/1fb7c61ca76c6fbff4d90b272e34e92bc2c7d729 --

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Serhiy Storchaka added the comment: New changeset 11909c12c75a7f377460561abc97707a4006fc07 by Serhiy Storchaka in branch '3.10': [3.10] Remove a NEWS entry for bpo-45878 (GH-30258) https://github.com/python/cpython/commit/11909c12c75a7f377460561abc97707a4006fc07 --

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Change by miss-islington : -- pull_requests: +28481 pull_request: https://github.com/python/cpython/pull/30260 ___ Python tracker ___

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Change by Serhiy Storchaka : -- pull_requests: +28480 pull_request: https://github.com/python/cpython/pull/30259 ___ Python tracker ___

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Change by Serhiy Storchaka : -- pull_requests: +28479 pull_request: https://github.com/python/cpython/pull/30258 ___ Python tracker ___

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Serhiy Storchaka added the comment: New changeset a9e0b2b49374df91c40fe409508cfcdc6332450e by Miss Islington (bot) in branch '3.10': bpo-45878: convert `try/except` to `self.assertRaises` in `Lib/ctypes/test/test_functions.py` (GH-29721) (GH-29748) https://github.com/python/cpython/commit

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Serhiy Storchaka added the comment: New changeset 393ff040281db818f2d6e0240919316f58f989a6 by Miss Islington (bot) in branch '3.9': bpo-45878: convert `try/except` to `self.assertRaises` in `Lib/ctypes/test/test_functions.py` (GH-29721) (GH-29723) https://github.com/python/cpython/commit

[issue46136] "dh low key " issue when try to connect mysql

Christian Heimes added the comment: DH_KEY_TOO_SMALL means that you are using weak and easy to break keys for your connections. Recent versions of OpenSSL prevent insecure connections. You can lower the security setting for a context with: >>> import ssl >>> context =

[issue46136] "dh low key " issue when try to connect mysql

open title: "dh low key " issue when try to connect mysql type: resource usage versions: Python 3.10 Added file: https://bugs.python.org/file50504/issue.txt ___ Python tracker <https://bug

[issue45890] Add tests for tracing try-except-finally blocks

Change by Irit Katriel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue45890] Add tests for tracing try-except-finally blocks

New submission from Mark Shannon : New changeset a310fd83a014484b8c680de83540c4908b344c6c by Irit Katriel in branch 'main': bpo-45890: Add tests for tracing try-except-finally blocks (GH-29746) https://github.com/python/cpython/commit/a310fd83a014484b8c680de83540c4908b344c6c -- nosy

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Change by Nikita Sobolev : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Change by miss-islington : -- pull_requests: +27985 pull_request: https://github.com/python/cpython/pull/29748 ___ Python tracker ___

[issue45890] Add tests for tracing try-except-finally blocks

Change by Irit Katriel : -- keywords: +patch pull_requests: +27983 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29746 ___ Python tracker ___

[issue45890] Add tests for tracing try-except-finally blocks

Change by Irit Katriel : -- assignee: iritkatriel components: Interpreter Core, Tests nosy: iritkatriel priority: normal severity: normal status: open title: Add tests for tracing try-except-finally blocks type: enhancement versions: Python 3.11

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Change by Alex Waygood : -- versions: +Python 3.10, Python 3.11, Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Serhiy Storchaka added the comment: New changeset b48ac6fe38b2fca9963b097c04cdecfc6083104e by Nikita Sobolev in branch 'main': bpo-45878: convert `try/except` to `self.assertRaises` in `Lib/ctypes/test/test_functions.py` (GH-29721) https://github.com/python/cpython/commit

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Change by miss-islington : -- pull_requests: +27960 pull_request: https://github.com/python/cpython/pull/29723 ___ Python tracker ___

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Change by miss-islington : -- nosy: +miss-islington nosy_count: 1.0 -> 2.0 pull_requests: +27959 pull_request: https://github.com/python/cpython/pull/29722 ___ Python tracker

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

Change by Nikita Sobolev : -- keywords: +patch pull_requests: +27957 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29721 ___ Python tracker ___

[issue45878] Use `self.assertRaises` instead of `try/except` in `ctypes/test_functions.py::test_mro`

New submission from Nikita Sobolev : Right now this test uses `try: ... except TypeError: ...` to ensure that mro is consistent. This has a flaw: code in `try` might not ever raise and this test would still pass. I will refactor it to use `self.assertRaises` to be 100% sure

Is the bug reported to python Recently i upgraded my python version and its directory But when i try to download pyqt5 it gives out a holy error Do i have to install py 3.9 again pls help me take a lo

-- https://mail.python.org/mailman/listinfo/python-list

[issue45276] avoid try 1000 in asyncio all_tasks by making weak collection .copy() atomic

Change by Thomas Grainger : -- keywords: +patch pull_requests: +26925 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28541 ___ Python tracker ___

[issue45276] avoid try 1000 in asyncio all_tasks by making weak collection .copy() atomic

messages: 402544 nosy: asvetlov, graingert, yselivanov priority: normal severity: normal status: open title: avoid try 1000 in asyncio all_tasks by making weak collection .copy() atomic versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <ht

[issue27277] Test runner should try to increase stack size if it is too low

STINNER Victor added the comment: I just pushed a change to reduce the stack memory usage when deleting a chain of exceptions in bpo-44348. I consider that this issue is a duplicate. If it's not the case, please reopen the issue. commit fb305092a5d7894b41f122c1a1117b3abf4c567e

[issue27277] Test runner should try to increase stack size if it is too low

Change by Irit Katriel : -- components: -Interpreter Core nosy: +iritkatriel, serhiy.storchaka title: Fatal Python error: Segmentation fault in test_exceptions -> Test runner should try to increase stack size if it is too low type: crash -> enhancement versions: +Python 3.11 -

[issue44917] interpreter hangs on recursion in both body and handler of a try block

Irit Katriel added the comment: Right, this is a duplicate of issue42951. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Random and infinite loop in dealing with recursion error for "try-except "

[issue44917] interpreter hangs on recursion in both body and handler of a try block

Mark Shannon added the comment: A recursion limit of 30 is effectively infinite. With a debug build of 3.11, the time to execute grows very fast indeed, probably super-exponentially. mark@nero:~/repos/cpython$ time ./python ~/test/test.py 15 real0m1.107s user0m1.099s sys

[issue44917] interpreter hangs on recursion in both body and handler of a try block

Irit Katriel added the comment: Not sure. Here we do set the recursion limit. -- ___ Python tracker ___ ___ Python-bugs-list

[issue44917] interpreter hangs on recursion in both body and handler of a try block

Mark Shannon added the comment: This looks like a duplicate of https://bugs.python.org/issue42951 -- nosy: +Mark.Shannon ___ Python tracker ___

[issue44917] interpreter hangs on recursion in both body and handler of a try block

Irit Katriel added the comment: Perhaps the interpreter should detect that it is about to raise a RecusionError whose context is another RecursionError, and raise a FatalError instead? -- ___ Python tracker

[issue44917] interpreter hangs on recursion in both body and handler of a try block

(): global count count += 1 try: f() except RecursionError: f() sys.setrecursionlimit(30) try: f() except RecursionError: pass main() print(count) --- When I kill it the traceback shows it alternating between the two recursive calls

[issue44305] Improve syntax error for try block without finally or except block

Pablo Galindo Salgado added the comment: New changeset e53f72a1b42e17a331ed14bec674b1ee01d0720c by Pablo Galindo in branch '3.10': [3.10] bpo-44305: Improve syntax error for try blocks without except or finally (GH-26523) (GH-26524) https://github.com/python/cpython/commit

[issue44305] Improve syntax error for try block without finally or except block

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue44305] Improve syntax error for try block without finally or except block

Change by Pablo Galindo Salgado : -- pull_requests: +25118 pull_request: https://github.com/python/cpython/pull/26524 ___ Python tracker ___

[issue44305] Improve syntax error for try block without finally or except block

Pablo Galindo Salgado added the comment: New changeset b250f89bb7e05e72a4641d44b988866b919575db by Pablo Galindo in branch 'main': bpo-44305: Improve syntax error for try blocks without except or finally (GH-26523) https://github.com/python/cpython/commit

[issue44305] Improve syntax error for try block without finally or except block

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +25117 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26523 ___ Python tracker

[issue44305] Improve syntax error for try block without finally or except block

New submission from Pablo Galindo Salgado : Given this script: try: x = 34 a = 1 instead of printing: File "/home/pablogsal/github/python/master/lel.py", line 4 a = 1 ^ SyntaxError: invalid syntax we should print: File "/home/pablogsal/github/python/master/

[issue42739] Crash when try to disassemble bogus code object

Change by Mark Shannon : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue42739] Crash when try to disassemble bogus code object

Mark Shannon added the comment: New changeset c76da79b37d2bcbe575cc927ba0a9b7a9ce465db by Mark Shannon in branch 'master': bpo-42739: Don't use sentinels to mark end of line table. (GH-25657) https://github.com/python/cpython/commit/c76da79b37d2bcbe575cc927ba0a9b7a9ce465db --

[issue42739] Crash when try to disassemble bogus code object

Change by Mark Shannon : -- keywords: +patch pull_requests: +24348 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25657 ___ Python tracker ___

[issue42739] Crash when try to disassemble bogus code object

Mark Shannon added the comment: Using sentinels as a marker to terminate the line number table, might be a problem if we want to use a different format. So I'm fixing this for 3.10. -- ___ Python tracker

[issue17519] unittest should not try to run abstract classes

Stephen Thorne added the comment: I have done some experimentation here and thought through this feature request. The concept we are trying to deliver is: "I would like to share functionality between test classes, by having an abstract parent, with concrete leaves" The metaclass abc.ABCMeta

[issue17519] unittest should not try to run abstract classes

Nathaniel Manista added the comment: michael.foord: I am now persuaded that the feature requested here ought be reconsidered (since my last comment there's been a lot of chatter about it behind closed doors at work, but I can at least cite https://github.com/abseil/abseil-py/issues/166 as a

[issue43458] Tutorial should mention about variable scope in try/except/finally

Éric Araujo added the comment: The only blocks that create scopes are modules, class and functions. if, try, with, for, while, etc are blocks but not new scopes. For the tutorial it could be nice to have an explicit mention and example of this. -- nosy: +eric.araujo

[issue17519] unittest should not try to run abstract classes

Nathaniel Manista added the comment: In the years since this was considered and declined, I wonder if the facts have changed sufficiently to make it now worth doing? I often find myself writing TestCases for interfaces, and those define test_* methods that call the interface under test, but

[issue43458] Tutorial should mention about variable scope in try/except/finally

New submission from Marek M : It can be helpful to mention that variables defined in try block are visible in except/finally block as well. I did not find this info in Python tutorial and for me (having C++ background) this is quite unexpected feature. -- assignee: docs@python

Re: try to install Python3.9.2 / setup failed

r, like an antivirus program). Often these kinds of problems don't have a lot to do with the thing being installed, and do have a lot to do with other conditions. In my experience, this means you need to run some of the fixit tools to make sure your system doesn't have corruption that i

Re: try to install Python3.9.2 / setup failed

Hello Python Team, i tried to install SW above; the installation stopped with the message "one or more issues caused the setup to fail. Please the issues and then retry 0x80070642 installation stopped by user" What must i do go get the SW installed? Windows 10, file "python-3.9.2-amd64.exe"

[issue15182] find_library_file() should try to link

Steve Dower added the comment: Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils. If this issue does not relate to distutils, please remove the component and reopen it. If

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

Mark Shannon added the comment: Sorry. I forgot the close the issue when it was fixed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

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

Ned Batchelder added the comment: This problem no longer appears with master (commit 9eb11a139f). -- ___ Python tracker ___ ___

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

Pablo Galindo Salgado added the comment: Friendly reminder that this issue is currently blocking the 3.10a5 release. If you are ok with waiting for the next release to include the fix, please say so here or drop me an email/ -- nosy: +pablogsal

[issue33387] Simplify bytecodes for try-finally, try-except and with blocks.

Change by Irit Katriel : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33387] Simplify bytecodes for try-finally, try-except and with blocks.

Mark Shannon added the comment: New changeset dea5bf9d15999bfcc58095b157c0678d45b00bdd by Irit Katriel in branch 'master': bpo-33387: update documentation for exception handling opcode changes (GH-24334) https://github.com/python/cpython/commit/dea5bf9d15999bfcc58095b157c0678d45b00bdd

[issue33387] Simplify bytecodes for try-finally, try-except and with blocks.

Irit Katriel added the comment: There's another place that needs to be updated: https://docs.python.org/3/library/dis.html#opcode-SETUP_WITH need to replace WITH_CLEANUP_START by WITH_EXCEPT_START -- ___ Python tracker

[issue33387] Simplify bytecodes for try-finally, try-except and with blocks.

Change by Irit Katriel : -- status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33387] Simplify bytecodes for try-finally, try-except and with blocks.

Change by Irit Katriel : -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list

[issue33387] Simplify bytecodes for try-finally, try-except and with blocks.

Irit Katriel added the comment: I'm reopening this to delete an obsolete comment left behind. -- nosy: +iritkatriel status: closed -> open ___ Python tracker ___

[issue33387] Simplify bytecodes for try-finally, try-except and with blocks.

Change by Irit Katriel : -- pull_requests: +23153 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/24334 ___ Python tracker ___

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

Change by Mark Shannon : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

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

Mark Shannon added the comment: Yes, see PEP 651 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Xinmeng Xia added the comment: oh,I see. By the way, I set the argument of sys.setrecursionlimit to 10 in this program and a segmentation fault is reported. Is that normal? -- ___ Python tracker

[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.Shannon

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

Serhiy Storchaka added the comment: Funny. But the output is not random. You can generate the sequence of letters by the following simple loop: s = '' for i in range(n): s = f'a{s}b{s}' The length of this sequence is 2*(2**n-1). Finally, your code will raise a non-silenced

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

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

New submission from Xinmeng Xia : In issue 42500, recursive calls in "Try-except" are resolved. This PR has fixed the crashes of some programs, such as program 1. And the core dump error is replaced with RecursiveError. However, program 2 will not report a RecursiveError. T

[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 ___

[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 ___ ___

[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/3bd6035b6baf1a7d51b7cc2c6bb2c81886236b67

[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 ___

[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

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

Mark Dickinson added the comment: > I don't see what the problem is here. People just don't write code like that. Yes, agreed; as I said in the original post, I'm not expecting any action, but the effect did seem interesting enough to be worth noting in an issue (if only so that it can be

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

Mark Dickinson added the comment: > And there may be more than one return/break/continue statement in the try > block. It increases the base of the degree. Ah, interesting. My understanding was that that can't happen, but I'll double check. In the control flow, all 'return' stat

[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 extra memory.

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

Serhiy Storchaka added the comment: And there may be more than one return/break/continue statement in the try block. It increases the base of the degree. At least for "return" we perhaps can merge different cases. But it would complicate the compiler and cannot help in o

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

(): while True: try: if something(): break elif something_else(): continue elif yet_something_else(): return finally: try: if something(): break elif something_else(): continue elif

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

New submission from Mark Dickinson : tl;dr - contrived (but relatively short) code involving nested try/finally blocks can produce disproportionately large bytecode. I'm not expecting or suggesting any action here, but the situation seemed at least worth noting. Feel free to close this issue

[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_CONST 0 (None) 2 RETURN_VALUE The

[issue42739] Crash when try to disassemble bogus code object

Ammar Askar added the comment: This seems to be part 2 of the problems Mark mentioned in issue42562. Namely in this case the `co_lnotab` accessor uses PyLineTable_NextAddressRange which has that assertion. -- nosy: +ammar2 ___ Python tracker

[issue42739] Crash when try to disassemble bogus code object

mped) It is expected that executing bogus code object can crash (or cause any other effect). But it is surprising that just inspecting it causes a crash. -- components: Interpreter Core messages: 383741 nosy: Mark.Shannon, serhiy.storchaka priority: normal severity: normal status: open

  1   2   3   4   5   6   7   8   9   10   >