Looks like global scope names in nested closures aren't getting resolved correctly?

Looks like global scope names in nested closures aren't getting resolved correctly?

Yes, the error is same as before.
Symtable thik object's context is assign when symtable analyze `registry[objcect] = func', and then think object is a local variable

Looks like global scope names in nested closures aren't getting resolved correctly?

import symtable
content = open("Lib/functools.py").read()
table = symtable.symtable(content, "?", "exec")
// True in python
// False in RustPython
table.lookup("singledispatch").get_namespace().lookup("object").is_global()
"""

RustPython‘s LoadLocal is not same as cpython's LoadFast.

def f():
  ch = chr (100)
  if ch == 'd':
    chr = ch
  return chr

"""
Bytecode:
  2           0 LOAD_FAST                0 (chr)
              2 LOAD_CONST               1 (100)
              4 CALL_FUNCTION            1
              6 STORE_FAST               1 (ch)

  3           8 LOAD_FAST                1 (ch)
             10 LOAD_CONST               2 ('d')
             12 COMPARE_OP               2 (==)
             14 POP_JUMP_IF_FALSE       20

  4          16 LOAD_FAST                1 (ch)
             18 STORE_FAST               0 (chr)

  5     >>   20 LOAD_FAST                0 (chr)
             22 RETURN_VALUE
"""

Cpython analyze chr's scope is Local, and use LoadFast to load chr, but we can't load chr if we use LoadName local.
@coolreader18 Do you have any suggestions for handling this situation？

@coolreader18 Current _codecss.py implemention is illegal in cpython.
In PyUnicode_DecodeUnicodeEscape function, chr referenced before assignment, and it will throw unbound error in cpython

Hmm, that is tricky. Maybe we could do something in symtable to check if it's used global scope and then reassigned, to do a less optimized LoadName for it after? Or maybe we could just copy CPython's LoadFast, if feasible?

@coolreader18 I think that modifying the symtable will destroy the compatibility with cpython.
Current _codecs.PyUnicode_DecodeUnicodeEscape will throw unbound error in cpython, a simple example is as follows.

Maybe we need to update the implementation of _codecs.py

Oh, I think we sent our comments at the same time, I didn't see yours before I sent mine. Yeah, I think the "reference before assignment" error + editing _codecs.py is the best course of action; the original version was from a PyPy branch compatible w/ python2 and there's been issues that pop up with it whenever a new module is added that calls into a part of _codecs that we haven't fixed yet.