Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider running activate() in macropy.__init__ #93

Open
gilch opened this issue Mar 23, 2019 · 2 comments
Open

Consider running activate() in macropy.__init__ #93

gilch opened this issue Mar 23, 2019 · 2 comments

Comments

@gilch
Copy link

gilch commented Mar 23, 2019

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?

@azazel75
Copy link
Collaborator

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.

@gilch
Copy link
Author

gilch commented Mar 23, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants