This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Warning 'assignment shadows builtin' __builtins__ fix
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: nascheme Nosy List: gvanrossum, nascheme, troelst
Priority: normal Keywords: patch

Created on 2003-07-09 13:13 by troelst, last changed 2022-04-10 16:09 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
py2.diff troelst, 2003-07-09 13:13 Patch to Objects/moduleobject.c
shadow_builtin.diff nascheme, 2003-07-16 18:31
Messages (6)
msg44246 - (view) Author: Troels Therkelsen (troelst) Date: 2003-07-09 13:13
Python 2.3b2 (#1, Jun 30 2003, 13:04:39) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import sys, new
>>> d = {'__builtins__':{}}
>>> d['mod'] = new.module('mod')
>>> d['mod'].__builtins__ = d['__builtins__']
>>> exec "mod.reload = 42" in d
<string>:1: DeprecationWarning: assignment shadows 
builtin
>>> d['sys'] = sys
>>> exec "print sys._getframe().f_builtins" in d
{}

Surely, the DeprecationWarning shouldn't be printed if 
you use __builtins__ to explicitly define your own builtins 
dict?  I mean, the 'reload' name in this case is an 
unknown name until it is defined in mod.

The submitted patch fixes Objects/moduleobject.c so 
that the warning is only done if the module global you're 
assigning to exists in f_builtins.  The patch is somehwat 
naive I admit, and it reuses as much as the old code as 
possible.  Alternatively, instead of all the work done, one 
could just check directly in f_builtins.
msg44247 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-07-10 18:21
Logged In: YES 
user_id=35752

I'm not sure what's the right thing to do here.  One simple
(I think) solution would be to not warn if __builtins__ are
overridden.  We don't want to implement anything too
complicated since the 2.3 is quickly approaching.  Hopefully
Guido can give me a clue as to what kind of a solution he
would like to see.
msg44248 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-07-16 16:10
Logged In: YES 
user_id=6380

Not warning if __builtins__ is overridden sounds like a fine
compromise to me. I believe Neal is on vacation -- who's
going to fix this?
msg44249 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-07-16 17:30
Logged In: YES 
user_id=35752

No vacation for me.  I'll take a crack at it.
msg44250 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-07-16 18:31
Logged In: YES 
user_id=35752

I think the attached patch does the trick.  Please review. 
I've changed the fuction that builds the set of "official"
builtin names to use PyThreadState_Get()->interp->builtins
rather than PyEval_GetBuiltins().  We don't want to end up
using some overridden builtins as the "official" builtin
names.  Next, I've changed the module setattr to check if
PyThreadState_Get()->interp->builtins ==
PyEval_GetBuiltins().  If not then the builtins are
overridden and the shadow test is skipped.

Is using PyThreadState_Get()->interp->builtins okay?  You
had previously suggested finding the builtin names using
sys.modules['__builtin__'].
msg44251 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-07-17 16:35
Logged In: YES 
user_id=35752

The warning code has been removed so this patch is no longer
applicable.
History
Date User Action Args
2022-04-10 16:09:53adminsetgithub: 38826
2003-07-09 13:13:42troelstcreate