Repository navigation
Ambiguous symbol table names #121914
Description
Feature or enhancement
Every symbol table has type and name. The name of the symbol table that corresponds a class or a function is the same as the name of the corresponding class or function. But there are special symbol tables of type function for lambdas and generator expressions (there were also symbol tables for comprehensions, but they are no longer used). For lambdas. the name "lambda" does not conflict with other function names, because it is a reserved word. But for general expressions, the name "genexpr" can conflict with local function "genexpr" (see #119698). It is possible to distinguish the symbol table corresponding to a generator expression by looking in the list of its parameters, but this is not so convenient.
I propose to make the difference more clear:
-
Either use separate types for lambda and generator expression symbol tables.
-
Or use names which cannot be confused with any function name:
- reserved word like
lambda. But I do not know good variant for generator expression. - hyphenated word, like
gen-expr. - angle brackets, like
<genexpr>and<lambda>. - other special characters, e.g.
.genexpr.
Names of symbol tables of other types like
topand__annotations__can also be changed for uniformity and to avoid possible future conflicts. - reserved word like
The original issue #119698 was solved in other way, so there is no urge for such change. This is just a wild idea.
Activity
JelleZijlstra commentedon Jul 17, 2024
I think a leading dot is a good approach to get a name that doesn't conflict with user-defined names: it always works and it's already what we do in a few other places in the compiler pipeline (e.g., PEP 695 annotation scopes can have a compiler-created local variable called
.type_params).picnixz commentedon Jul 17, 2024
Yes and I dislike that way although I couldn't come up with something else... It's a bit too fragile IMO =/
I'm actually happy with both proposals:
.type == TYPE_GENERATOR_EXPRESSIONwithout exposing any name. The issue is that you introduce more types but I'm not sure whether something else needs to be changed insymtable.c.genexprto be a hard keyword (or any other kind of name, like maybe__Py_genexprbut I don't think we gain anything here...). For brackets, I think it's already the case for therepr()but not in the symbol table itself.pythongh-121914: Change the names of the symbol tables for lambda and…
serhiy-storchaka commentedon Jun 9, 2025
New types for tables will require changing the compiler. Every time we check for FunctionBlock, we should add check for the new types. This can also affect third-party code. Special names would have less impact.
<genexpr>and<lambda>have the following advantages over.genexprand.lambda:<genexpr>and<lambda>are already defined, this will allow to reduce the number of static string objects.<listcomp>,<setcomp>and<dictcomp>for temporary symbol tables for zero cost.Class.meth.<genexpr>will look less ambiguous thanClass.meth..genexpr.serhiy-storchaka commentedon Jun 9, 2025
Since there may be several symbol tables with the same name, the name cannot be used to identify the symbol table. It is only used as a hint.
I would also change the name of the top symbol table to
<module>, but it is already documented as "top".gh-121914: Change the names of the symbol tables for lambda and genex…
pythongh-121914: Change the names of the symbol tables for lambda and…
pythongh-121914: Change the names of the symbol tables for lambda and…