We don't have a strict rule for this, but conventionally using this to distinguish local patch from failing tests.

The notation itself looks good.
But we use search tools for this comment. Keeping consistency will be helpful

Old habits die hard 😅

If we had test-passing symtable before, can these tests be easily fixed?

I think so, I think the main issue is that "symbols" attribute used to return a list, now it's a dict. I'll investigate a bit more about the structure. For now I'll set the PR as a draft

Thank you so much!

Now more tests pass. But we still have a difference between our impl and cpython. but this is a change that needs to be made at compiler/codegen/src/symboltable.rs, I think it's a bit out of scope for this PR. I'll try to do a followup PR to fix it

💡 Verification agent

Consider security implications of exposing memory addresses.

The id property exposes raw memory addresses, which could potentially be used for memory layout attacks or information disclosure in security-sensitive contexts.

Consider whether this aligns with CPython's behavior and if there are security implications for your use case:

🌐 Web query:

What does Python's symtable SymbolTable.id property return and are there security considerations?

💡 Result:

The id property (retrievable via get_id()) of Python's symtable.SymbolTable returns the table’s identifier, which is an internal value associated with that specific symbol table instance[1][2][5][6]. This identifier is primarily intended for internal use, such as distinguishing between different symbol table objects generated during code analysis.

Details:

• What does get_id() return?

  • The value returned by SymbolTable.get_id() is an identifier for that block's symbol table instance. It does not return the name of the function, class, or module—that is provided by get_name(). Instead, it gives an ID unique to the table, but published documentation does not specify if this is guaranteed to be globally unique, stable between runs, or even meaningful outside the context of the current symbol table introspection session[1][2][5][6].
  • Source-level guides and sample code (see [6]) show the use of get_id() alongside type and name to help programmers identify and differentiate symbol tables while traversing nested scopes.

• Security considerations:

  • There is no evidence in official documentation that the id or the value returned by get_id() contains sensitive information such as memory addresses, code contents, or pointers to user data[1][2][5][6].
  • However, since this is an internal identifier of a compiler structure, it is conceivable (though not specified) that in some Python implementations or versions, this ID could reveal patterns such as traversal order, or, hypothetically, even leak implementation details if misused.
  • In regular usage (introspecting Python source structures for tooling or analysis), exposure of the symbol table ID should not represent a direct security vulnerability, but best practice is to treat all such internal or undocumented identifiers as an implementation detail—do not expose them in sensitive contexts (such as web output, logs with user data, etc.) unless necessary.

Summary Table of Relevant SymbolTable Methods:

If you require a value that is stable and reveals no internal information, prefer using get_name() or a custom mapping on your analysis layer instead of exposing the value from get_id().

References:
[1][2][5][6]: Python's official symtable module documentation and tutorials.

Citations:

• 1: https://documentation.help/python-3-7-3/symtable.html
• 2: https://omz-software.com/pythonista/docs-3.4/py3/library/symtable.html
• 3: https://github.com/python/cpython/blob/main/Python/symtable.c
• 4: https://web.cs.dal.ca/~dpc/2023-06-22-icpc-open/docs/python/library/symtable.html
• 5: https://python.readthedocs.io/fr/stable/library/symtable.html
• 6: https://eli.thegreenplace.net/2010/09/20/python-internals-symbol-tables-part-2
• 7: https://www.cc.kyoto-su.ac.jp/~atsushi/Programs/VisualWorks/CSV2HTML/CSV2HTML_PyDoc/symtable.html
• 8: https://introcs.cs.princeton.edu/python/44st/
• 9: https://github.com/k2-fsa/k2/blob/master/k2/python/k2/symbol_table.py
• 10: https://tenthousandmeters.com/blog/python-behind-the-scenes-2-how-the-cpython-compiler-works/

Align SymbolTable.id() with CPython’s get_id(): avoid exposing raw pointers

The current implementation in vm/src/stdlib/symtable.rs returns the struct’s memory address as a usize, which diverges from CPython’s symtable.SymbolTable.get_id() (an internal, opaque identifier) and can leak pointer layouts.

Suggested changes:

• Replace the pointer cast in fn id(&self) -> usize with a dedicated, incrementing identifier (e.g., an AtomicUsize counter or per‐table UID stored on creation).
• Ensure IDs are unique within a run but do not expose raw addresses.
• Update documentation to note that id() returns an internal symbol-table ID, not a memory address.

Locations to update:

• vm/src/stdlib/symtable.rs, lines ~170–173 (the fn id(&self) definition)

Example diff sketch:

-   #[pygetset]
-   fn id(&self) -> usize {
-       self as *const Self as *const std::ffi::c_void as usize
-   }
+   // Use an internal counter instead of raw pointer to avoid leaking memory addresses
+   #[pygetset]
+   fn id(&self) -> usize {
+       self.inner_id  // populated from a global AtomicUsize at creation
+   }

Committable suggestion skipped: line range outside the PR's diff.

In vm/src/stdlib/symtable.rs around lines 170 to 173, the id() method currently
returns the raw memory address cast to usize, which exposes internal pointer
details and differs from CPython's opaque get_id(). To fix this, replace the
pointer cast with a unique internal identifier generated via a static
AtomicUsize counter incremented for each new SymbolTable instance or assign a
unique ID at creation stored in the struct. Update the id() method to return
this stored unique ID instead of the pointer. Also, revise the method's
documentation to clarify that id() returns an internal symbol table identifier,
not a memory address.

let's not delete these methods but change to getset, just like get_name and get_lineno.
Unlike other more complex cases, the deletion of these 2 methods cause unnecessary regression.

Fix this. And made type to return an int instead of a String, so now more tests pass

💡 Verification agent

Verify integer constant mapping for type property.

The typ() method now returns integer constants instead of strings, which is a significant interface change. The mapping looks reasonable, but the fallback to -1 for unhandled cases may not align with CPython's behavior.

🏁 Script executed:

#!/bin/bash
# Check CPython's SymbolTable.get_type() return values
python3 -c "
import symtable
st = symtable.symtable('def f(): pass', '<string>', 'exec')
print('Module type:', repr(st.get_type()))
for child in st.get_children():
    print('Function type:', repr(child.get_type()))
"

Length of output: 297

Ensure type property matches CPython’s string-based API

CPython’s SymbolTable.get_type() returns strings like "module" and "function", not integer codes. Our Rust typ() currently returns integer constants and falls back to -1 for any unhandled cases, which:

• Breaks compatibility with existing users expecting string values
• Omits several type names (e.g. comprehensions, lambdas, generators) that CPython exposes

Please update the implementation to either:

• Return Python strings matching CPython’s names, or
• If you intentionally switch to integers, document the change clearly and replace the -1 fallback with a dedicated TYPE_UNKNOWN constant—and add mappings for all types in CPython’s C implementation.

Points to address:

• Decide on integer vs. string return type and update docs accordingly
• Remove the // TODO and implement mappings for missing CPython types (generator, lambda, comprehension, etc.)
• Eliminate the -1 fallback or replace it with a well-defined default constant

In vm/src/stdlib/symtable.rs lines 154 to 163, the typ() function currently
returns integer constants and uses -1 as a fallback, which breaks compatibility
with CPython's string-based SymbolTable.get_type() API and omits several type
names. To fix this, change the return type to Python strings matching CPython's
type names (e.g., "module", "function", "class", "generator", "lambda",
"comprehension"), remove the -1 fallback, and implement mappings for all missing
CPython types. Also update any related documentation to reflect the string
return type and remove the TODO comment.

💡 Verification agent

Significant interface change: symbols now returns dictionary instead of list.

The symbols property now returns a dictionary mapping symbol names to their flag bits, which is a major change from the previous list-based return. This appears to align better with how symbols are typically accessed.

🏁 Script executed:

#!/bin/bash
# Verify CPython's SymbolTable.get_symbols() return type and structure
python3 -c "
import symtable
st = symtable.symtable('x = 1', '<string>', 'exec')
symbols = st.get_symbols()
print('Type:', type(symbols))
if symbols:
    print('First symbol type:', type(symbols[0]))
    print('First symbol methods:', [m for m in dir(symbols[0]) if not m.startswith('_')])
"

Length of output: 639

Breaking change: symbols now returns dict instead of list

You’ve changed the symbols getter in vm/src/stdlib/symtable.rs (lines 197–205) from a list of Symbol objects to a dict[str, int]. In CPython, symtable.symtable(...).get_symbols() returns a list[Symbol] (each with methods like is_assigned(), get_name(), etc.), not a mapping of names to flag bits.

This will break any existing code that:

• Iterates over symbols as Symbol instances
• Calls methods on Symbol objects
• Relies on the return being a list

Please address this by one of the following:

• Revert symbols to return PyListRef of Symbol objects (e.g. vm.new_pyobj(symbol)) for compatibility
• Introduce a new method/property (e.g. symbol_flags) for the dict view, and preserve symbols as the list of Symbol
• If this breaking change is intentional, update the documentation/changelog to call it out clearly

In vm/src/stdlib/symtable.rs around lines 197 to 205, the symbols getter was
changed to return a dict mapping symbol names to flag bits, but in CPython it
returns a list of Symbol objects. To fix this, revert the symbols method to
return a PyListRef of Symbol objects by creating a list and adding each symbol
object (e.g. using vm.new_pyobj(symbol)) to it, preserving compatibility. If the
dict view is needed, add a new method or property like symbol_flags for that
purpose instead of changing symbols.