You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can't think of a good reason one would want to import macropy and not actually use any macros. It would prevent the kind of confusion seen in #90. It's not like this would get executed more than once, even if multiple modules use macropy, because the module would be cached in sys.modules after its first run.
Perhaps if you want to save the pre-expanded code with SaveExporter for performance reasons, you wouldn't want the overhead of the import hook either, but in that case why not strip out the now-useless macropy imports altogether as part of the pre-expansion process?
The text was updated successfully, but these errors were encountered:
I think it's better leave the choice to the developer. Even when running code with already expanded macros created using the SaveExporter it's often needed to import things from the macropy package.
Hm, yes macropy.__init__ might be too soon. Maybe the right place for the import macropy.activate is in macropy.core.macros.Macros.__init__? That way importing any macros would have activated them. Is activation required to define a macro, or just expand them?
Activation feels like a useless extra step currently.
I can't think of a good reason one would want to import macropy and not actually use any macros. It would prevent the kind of confusion seen in #90. It's not like this would get executed more than once, even if multiple modules use macropy, because the module would be cached in
sys.modules
after its first run.Perhaps if you want to save the pre-expanded code with SaveExporter for performance reasons, you wouldn't want the overhead of the import hook either, but in that case why not strip out the now-useless macropy imports altogether as part of the pre-expansion process?
The text was updated successfully, but these errors were encountered: