[issue462937] continue inside try confuses while loop

[admin]

Change by admin :


--
github: None -> 35206

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue406287] last try: INSTALL_SCRIPT

[admin]

Change by admin :


--
github: None -> 34076

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


--
github: None -> 33646

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


--
github: None -> 33647

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


--
github: None -> 33644

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


--
github: None -> 33628

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


--
github: None -> 32882

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


--
github: None -> 32831

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
pull_requests:  -29165

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
pull_requests: +29165
pull_request: https://github.com/python/cpython/pull/30986

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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


--

___
Python tracker 
<https://bugs.python.org/issue46458>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Irit Katriel  added the comment:

See also the discussion on https://github.com/faster-cpython/ideas/issues/226.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +patch
pull_requests: +28938
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30751

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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: 411137
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Optimise try-except code generation for the happy path
type: performance
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue46458>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

Change by miss-islington :


--
pull_requests: +28481
pull_request: https://github.com/python/cpython/pull/30260

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +28480
pull_request: https://github.com/python/cpython/pull/30259

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +28479
pull_request: https://github.com/python/cpython/pull/30258

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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/a9e0b2b49374df91c40fe409508cfcdc6332450e


--

___
Python tracker 
<https://bugs.python.org/issue45878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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/393ff040281db818f2d6e0240919316f58f989a6


--

___
Python tracker 
<https://bugs.python.org/issue45878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Heimes]

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 = ssl.create_default_context()
>>> context.set_ciphers("DEFAULT@SECLEVEL=1")

You need to figure out yourself how to pass an insecure context to your 
database connector.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ajith MsM]

New submission from Ajith MsM :

i have tried to connect my db using python 3.10. 
import module is mysql.connector.
db has installed in AWS. while excuting pycharm able to connect the db to get 
the output. 
using CMD prompt in windows not able to execute facing error like "dh low key" 
error code 2055. 


But able to connect and execute on python 3.9.9 verision could you please fix 
the 3.10 and above versions.

--
assignee: christian.heimes
components: SSL
files: issue.txt
messages: 408947
nosy: ajithmsm555, christian.heimes
priority: normal
severity: normal
status: 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://bugs.python.org/issue46136>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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: +Mark.Shannon

___
Python tracker 
<https://bugs.python.org/issue45890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nikita Sobolev]

Change by Nikita Sobolev :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

Change by miss-islington :


--
pull_requests: +27985
pull_request: https://github.com/python/cpython/pull/29748

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +patch
pull_requests: +27983
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/29746

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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

___
Python tracker 
<https://bugs.python.org/issue45890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alex Waygood]

Change by Alex Waygood :


--
versions: +Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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/b48ac6fe38b2fca9963b097c04cdecfc6083104e


--
nosy: +serhiy.storchaka

___
Python tracker 
<https://bugs.python.org/issue45878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

Change by miss-islington :


--
pull_requests: +27960
pull_request: https://github.com/python/cpython/pull/29723

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[miss-islington]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nikita Sobolev]

Change by Nikita Sobolev :


--
keywords: +patch
pull_requests: +27957
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/29721

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nikita Sobolev]

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.

--
components: Tests
messages: 406829
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Use `self.assertRaises` instead of `try/except` in 
`ctypes/test_functions.py::test_mro`
type: behavior

___
Python tracker 
<https://bugs.python.org/issue45878>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Umme Salma]

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

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

[Thomas Grainger]

Change by Thomas Grainger :


--
keywords: +patch
pull_requests: +26925
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28541

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Thomas Grainger]

New submission from Thomas Grainger :

the weak collections should have the same threadsafe/thread unsafe guarantees 
as their strong reference counterparts - eg dict.copy and set.copy are atomic 
and so the weak versions should be atomic also

--
components: Interpreter Core, asyncio
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 
<https://bugs.python.org/issue45276>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 (upstream/main, main)
Author: Victor Stinner 
Date:   Tue Sep 7 15:42:11 2021 +0200

bpo-44348: BaseException deallocator uses trashcan (GH-28190)

The deallocator function of the BaseException type now uses the
trashcan mecanism to prevent stack overflow. For example, when a
RecursionError instance is raised, it can be linked to another
RecursionError through the __context__ attribute or the __traceback__
attribute, and then a chain of exceptions is created. When the chain
is destroyed, nested deallocator function calls can crash with a
stack overflow if the chain is too long compared to the available
stack memory.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_exceptions.ExceptionTests.test_recursion_in_except_handler 
stack overflow on Windows debug builds

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 -Python 3.6

___
Python tracker 
<https://bugs.python.org/issue27277>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 "

___
Python tracker 
<https://bugs.python.org/issue44917>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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 0m0.008s
mark@nero:~/repos/cpython$ time ./python ~/test/test.py 16

real0m4.468s
user0m4.464s
sys 0m0.004s
mark@nero:~/repos/cpython$ time ./python ~/test/test.py 17

real0m20.968s
user0m20.928s
sys 0m0.040s
mark@nero:~/repos/cpython$ time ./python ~/test/test.py 18

real2m29.562s
user2m29.270s
sys 0m0.140s


I would expect ./python ~/test/test.py 30 to take millions of years.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Irit Katriel  added the comment:

Not sure. Here we do set the recursion limit.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

Mark Shannon  added the comment:

This looks like a duplicate of https://bugs.python.org/issue42951

--
nosy: +Mark.Shannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

New submission from Irit Katriel :

This was found while investigating issue44895. It may or may not be the cause 
of that issue.


The script below hangs on a mac (it's an extract from 
test_exceptions.test_recursion_in_except_handler).

---
import sys

count = 0
def main():

  def f():
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, but not in a regular pattern:


... [snipped a lot]

  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  [Previous line repeated 2 more times]
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
  File "/Users/iritkatriel/src/cpython/tt.py", line 13, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/tt.py", line 11, in f
f()
^^^
RecursionError: maximum recursion depth exceeded

During handling of the above exception, another exception occurred:

Traceback (most r

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

[Pablo Galindo Salgado]

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/e53f72a1b42e17a331ed14bec674b1ee01d0720c


--

___
Python tracker 
<https://bugs.python.org/issue44305>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +25118
pull_request: https://github.com/python/cpython/pull/26524

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Galindo Salgado]

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/b250f89bb7e05e72a4641d44b988866b919575db


--

___
Python tracker 
<https://bugs.python.org/issue44305>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +25117
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26523

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Galindo Salgado]

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/lel.py", line 4
a = 1
^
SyntaxError: expected 'except' or 'finally' block

--
messages: 395053
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax error for try block without finally or except block

___
Python tracker 
<https://bugs.python.org/issue44305>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42739] Crash when try to disassemble bogus code object

[Mark Shannon]

Change by Mark Shannon :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42739] Crash when try to disassemble bogus code object

[Mark Shannon]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42739] Crash when try to disassemble bogus code object

[Mark Shannon]

Change by Mark Shannon :


--
keywords: +patch
pull_requests: +24348
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/25657

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42739] Crash when try to disassemble bogus code object

[Mark Shannon]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17519] unittest should not try to run abstract classes

[Stephen Thorne]

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 provides functionality that means two things:

 - any class with this metaclass (so the class and all its subclasses, 
typically) that have @abc.abstractmethod or @abc.abstractproperty decorated 
methods will be treated as abstract
 - any class that is treated as abstract will raise an exception immediately, 
to make it clear to the programmer (and unit tests) that a programming error 
has occured.

Following this through, we end up with two ways in which this can go  wrong in 
unit testing if we ask our unit testing framework to not test abstract classes.

This is a complete example, with both failure modes illustrated:

Consider:

class AbstractTestCase(unittest.TestCase, metaclass=abc.ABCMeta):
  ...

class FooTest(AbstractTestCase):
  def foo(self):
return 1

In this case, AbstractTestCase will not be skipped: this is because without any 
abstract methods inside it: it's not actually considered 'abstract', and is a 
concrete class.

In the second case:

class AbstractTestCase(unittest.TestCase, metaclass=abc.ABCMeta):
  @abc.abstractmethod
  def foo(self):
...

  @abc.abstractmethod
   def bar(self):
...

class FooTest(AbstractTestCase):
  def foo(self):
return 1

In this case, because AbstractTestCase has 2 abstract methods, it will be 
skipped. No tests run. But also FooTest will be skipped because it has 1 
abstract method, and is therefore also abstract.

If this were a 'normal' program, we would see an exception raised when FooTest 
is instanciated, but because we're skipping tests in abstract classes, we skip 
all the tests and exit with success.

My gut feeling on this is that what we really want is a decorator that says: 
Skip this class, and only this class, explicitly. All subclasses are concrete, 
only this one is abstract.

--
nosy: +sthorne

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17519] unittest should not try to run abstract classes

[Nathaniel Manista]

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 public example of the 
question coming up).

Would it be appropriate to file a new issue? My issue tracker training brought 
me up to believe that it's better to reopen an existing closed issue in a 
circumstance like this, but I respect that that may not be the custom in this 
issue tracker, and besides I lack the permission in this issue tracker to 
reopen this issue. 

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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

___
Python tracker 
<https://bugs.python.org/issue43458>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17519] unittest should not try to run abstract classes

[Nathaniel Manista]

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 of course my TestCase needs to 
be abstract because I'm only testing an interface and not a concrete 
implementation of that interface. It's also the case when I'm writing this kind 
of test that I wish to use a type-checker, and if I can have my abstract 
TestCase inherit from unittest.TestCase, that will satisfy my type-checker's 
questions about why I believe my TestCase has all kinds of assert* methods 
defined that it doesn't otherwise see.

I currently have the impression that if this is cheap enough to do, it may be 
worth doing just for the ergonomics alone? It mightn't make anything impossible 
become possible to do, but I forecast that it would make something difficult to 
do much more straightforward to do.

(I remain a fan of the all-powerful load_tests protocol, but... often it's nice 
to escape all the responsibility that comes with use of it.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marek M]

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
components: Documentation
messages: 388407
nosy: deekox, docs@python
priority: normal
severity: normal
status: open
title: Tutorial should mention about variable scope in try/except/finally
type: enhancement
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue43458>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: try to install Python3.9.2 / setup failed

[Mats Wichmann]

On 3/1/21 10:46 AM, manfred.schm...@posteo.de wrote:

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"

Best Regards from Lake of Constance
Manfred Schmidt


With all due respect to the Microsoft folks here, Windows installation 
is a bit of a mess.  When it finds something it doesn't like, it tends 
to throw its hands up and give you back an error that has a chance of 
not being terribly helpful to you, the user: you get a hex code, and an 
error string that doesn't seem to apply (pretty sure your installation 
wasn't stopped by _you_, despite what it says, though it _possibly_ 
could have been stopped by an external actor, 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 is confusing it.  Try 
the ones from Microsoft - there's usually no need for third-party ones. 
I've had good luck with the one in the following link, though obviously 
no guarantees it will take care of this _specific_ issue:


https://support.microsoft.com/en-us/topic/fix-problems-that-block-programs-from-being-installed-or-removed-cca7d1b6-65a9-3d98-426b-e9f927e1eb4d
--
https://mail.python.org/mailman/listinfo/python-list

Re: try to install Python3.9.2 / setup failed

[manfred . schmidt]

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"

Best Regards from Lake of Constance
Manfred Schmidt

log-file:
[3314:32E8][2021-03-01T18:44:04]i001: Burn v3.11.1.2318, Windows v10.0 
(Build 19041: Service Pack 0), path: C:\Users\Manfred 
Schmidt\AppData\Local\Temp\{2E17A51D-2D6F-45A4-A0FE-7965AAB86107}\.cr\python-3.9.2-amd64.exe
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'ActionLikeInstalling' to value 'Installing'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'ActionLikeInstallation' to value 'Setup'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'ShortVersion' to value '3.9'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'ShortVersionNoDot' to value '39'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'WinVer' to value '3.9'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'WinVerNoDot' to value '39'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'InstallAllUsers' to value '0'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'InstallLauncherAllUsers' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'TargetDir' to value ''
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'DefaultAllUsersTargetDir' to value 
'[ProgramFiles64Folder]Python[WinVerNoDot]'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'TargetPlatform' to value 'x64'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'DefaultJustForMeTargetDir' to value 
'[LocalAppDataFolder]Programs\Python\Python[WinVerNoDot]'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'OptionalFeaturesRegistryKey' to value 
'Software\Python\PythonCore\[WinVer]\InstalledFeatures'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'TargetDirRegistryKey' to value 
'Software\Python\PythonCore\[WinVer]\InstallPath'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'DefaultCustomTargetDir' to value ''
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'InstallAllUsersState' to value 'enabled'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'InstallLauncherAllUsersState' to value 'enabled'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'CustomInstallLauncherAllUsersState' to value 
'[InstallLauncherAllUsersState]'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'TargetDirState' to value 'enabled'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'CustomBrowseButtonState' to value 'enabled'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_core' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_exe' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_dev' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_lib' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_test' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_doc' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_tools' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_tcltk' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_pip' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_launcher' to value '-1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing string variable 
'Include_launcherState' to value 'enabled'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_symbols' to value '0'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Include_debug' to value '0'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'LauncherOnly' to value '0'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'DetectedLauncher' to value '0'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'DetectedOldLauncher' to value '0'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'AssociateFiles' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'Shortcuts' to value '1'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'PrependPath' to value '0'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'CompileAll' to value '0'
[3314:32E8][2021-03-01T18:44:04]i000: Initializing numeric variable 
'SimpleInstall' to value '0'

[issue15182] find_library_file() should try to link

[Steve Dower]

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 you believe it still requires a fix, most likely the issue should 
be re-reported at https://github.com/pypa/setuptools

--
nosy: +steve.dower
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ned Batchelder]

Ned Batchelder  added the comment:

This problem no longer appears with master (commit 9eb11a139f).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Galindo Salgado]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Irit Katriel  added the comment:

I'm reopening this to delete an obsolete comment left behind.

--
nosy: +iritkatriel
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

Change by Irit Katriel :


--
pull_requests: +23153
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/24334

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

Change by Mark Shannon :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

Mark Shannon  added the comment:

Yes, see PEP 651

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Xinmeng Xia]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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

___
Python tracker 
<https://bugs.python.org/issue42951>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 RecursiveError, but it will just take some time (for printing 
around 2**1000 letters).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Xinmeng Xia]

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. The program will fall into 
an infinite loop. Even "Ctrl C" cannot stop the infinite loop. I try to track 
the execution of this program and insert "print" information(see program 3). 
The output seems random in execution between try branch and except branch!  I 
think this is a new bug after fixing 42500. I believe the program should also 
return RecursiveError.


Program 1
======= 
def foo():
try:
1/0
except:
foo()
foo()


Program 2
========
def foo():
try:
foo()
except:
foo()
foo()



Program 3
========
def foo():
try:
print("a")
foo()
except:
print("b")
foo()

foo()

Output for program3( unexpected infinite random loop. ):
..bbbbabbaabbabbaaabbabbaabbabbbbabbaabbabbaaabbabbaabbabbbbabbaabbabbaaabbabbaabbabbabbabbaabbabbaaabbabbaabbabbbbabbaabbabbaaabbabbaabbabbaabbabbaabbabbaaabbabbaabbabbbb..

>>python -V
Python 3.10.0a4

--
components: Interpreter Core
messages: 385171
nosy: xxm
priority: normal
severity: normal
status: open
title: Random and infinite loop in dealing with recursion error for "try-except 
"
type: behavior
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42951>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

Change by Mark Shannon :


--
pull_requests: +23036
pull_request: https://github.com/python/cpython/pull/24209

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

Change by Mark Shannon :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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


--

___
Python tracker 
<https://bugs.python.org/issue42908>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

Change by Mark Shannon :


--
keywords: +patch
pull_requests: +23027
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24202

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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

--
assignee: Mark.Shannon
messages: 384920
nosy: Mark.Shannon
priority: high
severity: normal
status: open
title: Incorrect line numbers at end of try-except and with statements 
containing if False: pass

___
Python tracker 
<https://bugs.python.org/issue42908>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 recorded as a known "feature" and the resolution can be 
recorded for the future).

I'll close as won't fix.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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' statements that leave a try block are 
going to the same place, so only one 'finally' branch needs to be generated no 
matter how many returns you have. And similarly for 'break' and 'continue'. 
IOW, what matters is the possible paths that can be taken when the finally 
block exits, and there are only up to 5 of those (for raise, return, break, 
continue, and leaving normally).

--

___
Python tracker 
<https://bugs.python.org/issue42873>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 other cases.

--
nosy: +serhiy.storchaka

___
Python tracker 
<https://bugs.python.org/issue42873>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

Mark Dickinson  added the comment:

For extra fun, you can add `break` and `continue` paths into the mix to get a 
5-fold instead of 3-fold  code size increase per level of nesting. It's still 
contrived code, though.

Example where do_cleanup() ends up with 5**4 = 625 paths:



def f():
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 yet_something_else(): return
finally:
try:
if something(): break
elif something_else(): continue
elif yet_something_else(): return
finally:
try:
if something(): break
elif something_else(): continue
elif yet_something_else(): return
finally:
do_cleanup()


--

___
Python tracker 
<https://bugs.python.org/issue42873>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 as a "well don't do that, then" (a.k.a. "wont 
fix")

Longer: Python 3.9 changed the way that bytecode was generated for try/finally 
(see #33387). For a "try" block body that can do any of raise, return or 
fall-off-the-end-of-the-block, the corresponding finally block gets three 
separate paths in the bytecode. If such trys are nested  times, we get 3^n 
separate paths in the bytecode.

Example code:

----
def f():
try:
if something(): return
finally:
try:
if something(): return
    finally:
try:
if something(): return
        finally:
try:
if something(): return
    finally:
try:
if something(): return
finally:
do_cleanup()


import dis
dis.dis(f)


On my machine, running this and counting the do_cleanup invocations gives, as 
expected, a result of 243 = 3**5

% python3.9 nested_finally.py | grep do_cleanup | wc -l 
 243

That's fairly benign, but if I scale up to 10 nested blocks, the dis.dis call 
takes over 10 minutes to complete (the compilation itself still only takes a 
fraction of a second). The bytecode object is correspondingly large:

>>> len(f.__code__.co_code)
1741356

With 15 levels of nesting, compilation takes several seconds, and
the generated code is (again as expected) a couple of orders of magnitude 
larger:

>>> len(f.__code__.co_code)
533859040

I didn't try pushing this further than 15 levels of nesting.

As I said above, it's not clear to me whether this is actually an issue that 
needs to be addressed in practice. It seems unlikely that "real code" :TM: 
would run into this, but the effect seemed worth noting.

--
components: Interpreter Core
messages: 384718
nosy: Mark.Shannon, mark.dickinson
priority: normal
severity: normal
status: open
title: Exponential time and space requirements for compilation of nested 
try/finally blocks
type: performance
versions: Python 3.10, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue42873>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42739] Crash when try to disassemble bogus code object

[Mark Shannon]

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 problem with the example Serhiy gives is that the line number table does 
not end in a sentinel value.

You shouldn't be creating code objects unless you really know what you are 
doing. I.e. never.

For manually created code objects that don't respect the invariants, any 
behavior is acceptable IMO.

--
assignee:  -> Mark.Shannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42739] Crash when try to disassemble bogus code object

[Ammar Askar]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42739] Crash when try to disassemble bogus code object

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

>>> def f(): pass
... 
>>> co = f.__code__.replace(co_linetable=b'')
>>> import dis
>>> dis.dis(co)
python: Objects/codeobject.c:1185: PyLineTable_NextAddressRange: Assertion 
`!at_end(range)' failed.
Aborted (core dumped)

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
title: Crash when try to disassemble bogus code object
type: crash
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42739>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com