How do I prevent macros from polluting the global namespace via import?

[glyh]

As title, I just wrote a macro that requires another namespace imported, but I don't want it to be visible to end user.
Yeah I can check if it's imported and delete it if it hasn't been, but itsn't there a more elegant way?

EDIT:
the problem is more than this, actually. I can't put this macro call everywhere simply because import has to go at the top of the file.
It's theroetically possible to wrap it around a function call to hide all details, but is there better way?

[Kodiologist]

import has to go at the top of the file

Not so. Python allows import wherever a statement is allowed, so long as it's not import *.

The way to import in a macro expansion is to use a gensym:

(defmacro m []
  (setv math (hy.gensym))
  `(do
    (import math :as ~math)
    ((. ~math sqrt) 2)))

(print (m))   ; => 1.4142135623730951
(print math)  ; => NameError: name 'math' is not defined

[glyh]

    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 879, in exec_module
  File "<frozen importlib._bootstrap_external>", line 1017, in get_code
  File "/home/lyh/.local/lib/python3.10/site-packages/hy/importer.py", line 126, in _hy_source_to_code
    return _py_source_to_code(self, data, path, _optimize=_optimize)
  File "<frozen importlib._bootstrap_external>", line 947, in source_to_code
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/home/lyh/.local/lib/python3.10/site-packages/chibicc_hy/adt.hy", line 1
    (defmacro defadt [name #* constructors]
    ^
SyntaxError: from __future__ imports must occur at the beginning of the file

I feel like to fix this there must be some kind of code transformation done in hy itself. I've found workaround not using future import .

[Kodiologist]

__future__ imports aren't real imports and don't affect any namespaces. They're just a way that Python provided to declare language variants without introducing a new keyword for it.

[glyh]

Yeah, and this would be solved automatically when future features are stablized.