The following code (not directly in an interpreter, but execute as file)
def top(deck):
pass
def b():
global deck
produces the error
SyntaxError: name 'deck' is local and global
on python2.6.4 and
SyntaxError: name 'deck' is parameter and global
on python 3.1
python2.4 seems to accept this code, so does the 2.6.4 interactive interpreter.
This is already odd; why is 'deck' conflicting if it's a global in one method and a parameter in the other?
But it gets weirder. Rename 'top' to basically anything else, and the problem disappears.
Can someone explain this behaviour? I feel like I'm missing something very obvious here. Is the name 'top' somehow affecting certain scoping internals?
Update
This indeed appears to be a bug in the python core. I have filed a bug report.
It looks like it is a bug in the symbol table handling. Python/symtable.c has some code that (although somewhat obfuscated) does indeed treat 'top' as a special identifier:
if (!GET_IDENTIFIER(top) ||
!symtable_enter_block(st, top, ModuleBlock, (void *)mod, 0)) {
PySymtable_Free(st);
return NULL;
}
followed somewhat later by:
if (name == GET_IDENTIFIER(top))
st->st_global = st->st_cur->ste_symbols;
Further up the file there's a macro:
#define GET_IDENTIFIER(VAR) \
((VAR) ? (VAR) : ((VAR) = PyString_InternFromString(# VAR)))
which uses the C preprocessor to initialise the variable top
to an interned string with the name of the variable.
I think the symbol table must be using the name 'top' to refer to the top level code, but why it doesn't use something that can't conflict with a real variable I have no idea.
I would report it as a bug if I were you.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With