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

Mark Shannon added the comment: With the introduction of zero cost exceptions, there is no block stack. -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker

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

Change by Mark Shannon : -- pull_requests: +30145 pull_request: https://github.com/python/cpython/pull/32055 ___ Python tracker ___

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

Change by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Guido van Rossum added the comment: Yes, if we keep the top of the stack and the current frame in separate variables.-- --Guido (mobile) -- ___ Python tracker ___

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

Serhiy Storchaka added the comment: > There are also other ideas floating about for improving memory locality > related to the frame stack, e.g. putting the stack frames in an array instead > of a linked list. Would it work with generators and coroutines? --

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

Guido van Rossum added the comment: I don't see what putting the limit back in this PR would give, but I do question that we need more block nesting, and this PR causes a lot of code churn (including a new API to create frames). It would be more convincing if you could actually point to a

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

Thomas Anderson added the comment: IIRC, some transpilers for functional languages create deeply nested code. In particular for things like haskell's do notation. Anyway, when I wrote the PR, it was initially to reduce the frame size. Then once I had dynamic block stack sizing working, I

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

Mark Shannon added the comment: I see no advantage of getting rid of the limit of 20. No one ever gets near 20 deep in practice. Given the limit has been there for so long, it is likely that some tooling that expects the depth of try-statements to be limited. Why would a code generator need

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

Thomas Anderson added the comment: > Reducing the size of the frame object seems like a worthwhile goal, but > what's the point in increasing the maximum block stack? No point for humans, but it may be useful for code generators. -- ___ Python

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

Serhiy Storchaka added the comment: Getting rid of hardcoded limits is good. And at first look the proposed PR looks good (some minor details can be discussed). Although there is different approach to solve the same problem. The stack of blocks is used to set handlers for exceptions. For

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

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

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

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 1.0 -> 2.0 pull_requests: +23029 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24204 ___ Python tracker

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

New submission from Thomas Anderson : Currently the block stack size is hardcoded to 20. Similar to how the value stack is dynamically sizable, we should make the block stack dynamically sizable. This will reduce space on average (since the typical number of blocks for a function is well