hy.eval called from python function and lfor

[syntonym]

I'm trying to use hy by calling it from a python function, but it seems that hy.eval behaves differently when called in a function than when it is called globally:

import hy

test1 = '(defn a [x] "a")'
test2 = '(lfor x [1 2 3] (a x))'
test3 = '(list (map a [1 2 3]))'

def eval_in_function():
    hy.eval(hy.read(test1))
    try:
        print(hy.eval(hy.read(test2)))
    except NameError:
        print("Function a not found")
    hy.eval(hy.read(test3))

eval_in_function()

hy.eval(hy.read(test1))
hy.eval(hy.read(test2))
hy.eval(hy.read(test3))

The lfor call does not work, but the map call does, just as the hy.eval in global scope. Apparently it is related to namespaces, so I tried to set the hy.eval namespace explicitly:

def eval_in_function():
    namespace = {}
    hy.eval(hy.read(test1), locals=namespace)
    try:
        print(hy.eval(hy.read(test2), locals=namespace))
    except NameError:
        print("Function a not found")
    hy.eval(hy.read(test3), locals=namespace)

which does not work, but setting namespace = globals() does work, but I don't understand why. Am I missing any scoping rules here? I'd greatly appreciate any pointers.

[Kodiologist]

I think this boils down to the most confusing aspect of Python's exec: "If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition", not as a function as you might expect. Notice that

>>> exec('print([b for x in [1]])', globals(), {"b": 3})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <listcomp>
NameError: name 'b' is not defined

and indeed

>>> class C:
...   b = 3
...   a = b + 3
...   c = [b for x in [1]]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in C
  File "<stdin>", line 4, in <listcomp>
NameError: name 'b' is not defined

Here's a Stack Overflow question about the latter. It's ridiculous, but it seems to be a won't-fix so long as the Python folks are concerned.

[syntonym]

Oh wow, that is very unexpected to me. Thanks for the great and quick answer.

So if I want to isolate the hy and python namespaces the following should work?

dummy_module = type(sys)("dummy_module")
hy.eval(hy.read(...), module=dummy_module, locals=dummy_module.__dict__)

[Kodiologist]

The easiest way to do it is something like

namespace = {}
hy.eval(hy.read(…), locals = namespace, module = namespace)

Ignore the type hints in the docstring of hy.eval. There have been a few attempts to type-annotate and typecheck Hy, but nobody could manage to do it, so the remaining type hints are unchecked, and in general not correct.

[syntonym]

That works, thanks. From reading the code I expected it not to work though. If I see correctly hy.eval first calls get_compiler_module which first tries to get the module attribute from the compiler (which should fail and return None), after which it is checked whether the module is a string, and then check calling_frame and not module which is True for the case of module = {}. In that case it just gets the calling module from the frame stack, so I expect the behavior to be the same for module = None.

But it works, so I'm happy. Thanks for the help!