-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Running Lib/test/test_funcattrs.py
directly fails
#122864
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The culprit is the def b(): pass
assert b.__builtins__ is __builtins__ I'm wondering why running this test using |
Could be something where there is an exec/eval polluting a namespace? I don't have access to sources so I cannot even check nut might be worth changing the name of the object being tested, or look at whether builtins is reloaded at some point? |
I think this part of the docs explains the behaviour: By default, when in the
markbyrne@Marks-Air-2 cpython % ./python.exe -m test.test_funcattrs
> /Users/markbyrne/programming/cpython/Lib/test/test_funcattrs.py(101)test___builtins__()
-> breakpoint()
(Pdb) __name__
'__main__'
(Pdb) __builtins__
<module 'builtins' (built-in)>
(Pdb) __builtins__.__dict__ is __builtins__
False
(Pdb)
> /Users/markbyrne/programming/cpython/Lib/test/test_funcattrs.py(101)test___builtins__()
(Pdb) __name__
'test.test_funcattrs'
(Pdb) import builtins
(Pdb) builtins.__dict__ is __builtins__
True
(Pdb) So, one way forward could be to update the test to first check if we are inside Edit: However, it isn't clear why Edit 2: I gather from https://bugs.python.org/issue42990 that --- a/Lib/test/test_funcattrs.py
+++ b/Lib/test/test_funcattrs.py
@@ -98,7 +98,23 @@ def test___globals__(self):
(AttributeError, TypeError))
def test___builtins__(self):
- self.assertIs(self.b.__builtins__, __builtins__)
+ if __name__ == "__main__":
+ # `func.__builtins__` is `builtins.__dict__`.
+ # See:https://bugs.python.org/issue42990
+
+ # When this test is run by executing the current module,
+ # `__builtins__` is the built-in module `builtins`.
+
+ # When this test is run from another module, `__builtins__` is
+ # `builtins.__dict__`
+ # See: https://docs.python.org/3/reference/executionmodel.html#builtins-and-restricted-execution
+
+ import builtins
+ builtins_dict = builtins.__dict__
+ else:
+ builtins_dict = __builtins__
+
+ self.assertIs(self.b.__builtins__, builtins_dict)
self.cannot_set_attr(self.b, '__builtins__', 2,
(AttributeError, TypeError))
@@ -108,7 +124,7 @@ def func(s): return len(s)
ns = {}
func2 = type(func)(func.__code__, ns)
self.assertIs(func2.__globals__, ns)
- self.assertIs(func2.__builtins__, __builtins__)
+ self.assertIs(func2.__builtins__, builtins_dict)
# Make sure that the function actually works. |
…le was run directly via: `python -m test.test_funcattrs`.
…directly (#124845) Previously when executing ``test_functattrs.test___builtins__`` directly, it failed because the fact, that ``__builtins__`` is refers to the built-in module ``builtins`` while it's expects a ``__builtins__.__dict__``. But when this test is being run from another module, then ``__builtins__`` is refers to ``builtins.__dict__``. Now this part of the behaviour is covered. --------- Co-authored-by: Victor Stinner <[email protected]>
…uting directly (pythonGH-124845) Previously when executing ``test_functattrs.test___builtins__`` directly, it failed because the fact, that ``__builtins__`` is refers to the built-in module ``builtins`` while it's expects a ``__builtins__.__dict__``. But when this test is being run from another module, then ``__builtins__`` is refers to ``builtins.__dict__``. Now this part of the behaviour is covered. --------- (cherry picked from commit 8fbf10d) Co-authored-by: Mark Byrne <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
…uting directly (pythonGH-124845) Previously when executing ``test_functattrs.test___builtins__`` directly, it failed because the fact, that ``__builtins__`` is refers to the built-in module ``builtins`` while it's expects a ``__builtins__.__dict__``. But when this test is being run from another module, then ``__builtins__`` is refers to ``builtins.__dict__``. Now this part of the behaviour is covered. --------- (cherry picked from commit 8fbf10d) Co-authored-by: Mark Byrne <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
…cuting directly (GH-124845) (#124885) gh-122864: Fix a ``test_funcattrs.test___builtins__`` when executing directly (GH-124845) Previously when executing ``test_functattrs.test___builtins__`` directly, it failed because the fact, that ``__builtins__`` is refers to the built-in module ``builtins`` while it's expects a ``__builtins__.__dict__``. But when this test is being run from another module, then ``__builtins__`` is refers to ``builtins.__dict__``. Now this part of the behaviour is covered. --------- (cherry picked from commit 8fbf10d) Co-authored-by: Mark Byrne <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
…cuting directly (GH-124845) (#124884) gh-122864: Fix a ``test_funcattrs.test___builtins__`` when executing directly (GH-124845) Previously when executing ``test_functattrs.test___builtins__`` directly, it failed because the fact, that ``__builtins__`` is refers to the built-in module ``builtins`` while it's expects a ``__builtins__.__dict__``. But when this test is being run from another module, then ``__builtins__`` is refers to ``builtins.__dict__``. Now this part of the behaviour is covered. --------- (cherry picked from commit 8fbf10d) Co-authored-by: Mark Byrne <[email protected]> Co-authored-by: Victor Stinner <[email protected]>
Thanks @mbyrnepr2! |
Bug report
Bug description:
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Linked PRs
test_funcattrs.test___builtins__
when executing directly #124845test_funcattrs.test___builtins__
when executing directly (GH-124845) #124884test_funcattrs.test___builtins__
when executing directly (GH-124845) #124885The text was updated successfully, but these errors were encountered: