Repository navigation
it's no longer possible to delete items from f_locals (FrameLocalsProxy) in 3.13+ #125590
Description
Activity
This sounds like an issue in the version of
pydevdbundled by the Microsoft Python extension.I assume it's related to the FrameLocalsProxy changes from PEP-667; cc @gaogaotiantian.
Maybe
FrameLocalsProxyshould just implement pop? (Or better yet, the rest of thedictinterface.)Maybe
FrameLocalsProxyshould just implement pop? (Or better yet, the rest of thedictinterface.)problem is you cannot remove items from FrameLocalsProxy:
Line 162 in d83fcf8
I think pydevd has to do
try: del frame.f_locals["__exception__"] except KeyError: pass except TypeError: frame.f_locals["__exception__"] = None
Reacted by Jelle ZijlstraThe reason why
FrameLocalsProxydid not supportpopanddelin the first place, is because it does not make sense to "remove" a local variable from the frame. However, in this specific case, the debugger is trying to remove an extra variable, which is artificially added. I think it might be fine to check if it's an actual local variable and only report error when it is.@markshannon and @gvanrossum as this was the discussion result from PEP 667 implementation.
Reacted by Peter BiermaI'm not particularly familiar with how PEP 667 was implemented. From my understanding, deleting from
f_localswas previously possible--is it that it can't be implemented right now, or is it that it's dangerous to expose to users?Popping and deleting keys in the "extras" dict should be fine.
It gets complicated when the key is a "fast" local.In the style of the PEP, this would give us:
def __delitem__(self, name): del self._extra_locals[name] def pop(self, name, default): return self._extra_locals.pop(name, default)
Reacted by Guido van RossumThe semantics of
f_localshas changed.f_localsused to be a pure dict which was written back to the real locals on certain occasions (the most common one is returning from trace functions). The old behavior, when you remove a key fromf_locals, if it was written back, was to set the local variable toNoneand generate a warning - a very inconsistent and confusing behavior.Popping and deleting keys in the "extras" dict should be fine. It gets complicated when the key is a "fast" local.
Let's allow popping and deleting keys in extras, and generate an exception (we are generating one now on
del) if the user tries to remove a real local variable. Do we consider this a bug so we need to backport it to 3.13?Reacted by Guido van Rossum- changed the title
[-]try except pass results in a script failure and system errors when code falls into pass logic - new bug in Python 3.13[/-][+]it's no longer possible to delete items from f_locals (FrameLocalProxy) in 3.13+[/+]on Oct 16, 2024 - changed the title
[-]it's no longer possible to delete items from f_locals (FrameLocalProxy) in 3.13+[/-][+]it's no longer possible to delete items from f_locals (FrameLocalsProxy) in 3.13+[/+]on Oct 16, 2024 The semantics of
f_localshas changed.f_localsused to be a pure dict which was written back to the real locals on certain occasions (the most common one is returning from trace functions). The old behavior, when you remove a key fromf_locals, if it was written back, was to set the local variable toNoneand generate a warning - a very inconsistent and confusing behavior.how do you generate the warning?
I tried this on 3.12 and didn't see a warning, and the local didn't get set to None:
import sys class A: pass def foo(): a = A() f_locals = sys._getframe().f_locals del f_locals['a'] print(a) print(f_locals) foo()
graingert@conscientious ~/projects python3.12 -Werror demo.py <__main__.A object at 0x7ae782f40230> {} graingert@conscientious ~/projects python3.13 -Werror demo.py Traceback (most recent call last): File "/home/graingert/projects/demo.py", line 15, in <module> foo() ~~~^^ File "/home/graingert/projects/demo.py", line 10, in foo del f_locals['a'] ~~~~~~~~^^^^^ TypeError: cannot remove variables from FrameLocalsProxyI tried this on 3.12 and didn't see a warning, and the local didn't get set to None:
This is the case where the
f_localsis not written back. Like I said, it was only written back on certain occasions, for example, when it returns from a trace function. And that's why we need to change it.Hello. Just checking back on this bug. Is there a plan to fix it and update the current Python 3.13 version with the fix? If so, when is that expected so I can reinstall Python 3.13? Thanks.
The fix is in #125590 and it should be merged soon. We don't update the current version of 3.13, so 3.13.0 will be always like this without the fix. However, 3.13.1 should come up with the fix. It's estimated to be released two months after 3.13.0 so probably December.
Reacted by Deana Garrott (113908)- added a commit that references this issue
on Oct 21, 2024 - added a commit that references this issue
on Oct 21, 2024 The fix is in #125590 and it should be merged soon. We don't update the current version of 3.13, so 3.13.0 will be always like this without the fix. However, 3.13.1 should come up with the fix. It's estimated to be released two months after 3.13.0 so probably December.
Has version 3.13.1 been released yet?
Expected on the 12th https://peps.python.org/pep-0719/#bugfix-releases
I believe the release is currently in progress, actually. The announcements should come shortly.
- Reacted by Edgar Ramírez Mondragón
- added a commit that references this issue
on Aug 8, 2025
Bug report
Bug description:
In the example script above, if the code falls into the except: pass block due to an alert not being displayed, the script will ultimately fail (even if no coding errors are encountered) with FAILED (errors=1) .
Also, the following messages will be displayed in the output:
This code works fine in Python 3.12. The script succeeds with message OK and none of the above error messages. We can't move to 3.13 version until this is fixed.
CPython versions tested on:
3.13
Operating systems tested on:
Windows
Linked PRs