-
Notifications
You must be signed in to change notification settings - Fork 119
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
Add Import Tolerance #216
Add Import Tolerance #216
Conversation
Great idea and it, relates to the 2nd goal of #214. This will be a valuable pull request as it addresses one of the many paper cut issues with our current system. |
@Versatilus would have insight on implementation. |
For extra clarification, @Versatilus, would It be ok if I mess with the globals dictionary to emulate |
Feel free to experiment as needed. |
This definitely looks like the right direction to me. Ideally, this process should be entirely dynamic, which might require refactoring some of the modules for consistent names. I'm still thinking about the whole process. In the interest of future portability, I think you might want to look into |
caster/lib/ccr/core/nav.py
Outdated
@@ -107,7 +107,7 @@ class Navigation(MergeRule): | |||
lambda fnparams: UntilCancelled(Mimic(*filter(lambda s: s != "periodic", fnparams)), 1).execute(), \ | |||
use_spoken=True))]), | |||
# VoiceCoder-inspired -- these should be done at the IDE level | |||
"fill <target>": R(Key("escape, escape, end"), show=False) + | |||
"fill <target>": R(Key("escape, escape"), show=False) + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious what this change is about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An experiment which l forgot to remove. I have restored the original files in the next commits.
I'm having issues with getting importlib to find the modules. Using globals() with import worked but no matter what package or module name I try with importlib, it won't find them. I'm guessing it has to do with how they are imported by by the rest of the caster framework. |
I just played around with this a bit and I figured it out. The first argument to __temp__ = importlib.import_module(".lib.ccr." + module_name, package="caster")
module = getattr(__temp__, class_name) is just as valid as __temp__ = importlib.import_module("caster.lib.ccr." + module_name)
module = getattr(__temp__, class_name) I have some ideas I can elaborate on in a few hours. |
So any ideas? The current implementation works pretty well and will be portable to python 3 with importlib's import though. |
"sql.sql": ("SQL", ), | ||
"prolog.prolog": ("Prolog", ), | ||
"vhdl.vhdl": ("VHDL", ), | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would really like to make this list automatically. I just haven't settled on the implementation strategy.
for module_name,class_name_tup in command_sets.iteritems(): | ||
for class_name in class_name_tup: | ||
try: | ||
module = __import__(module_name, globals(), locals(),[class_name]) #attempts to import the class |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works well, so I'll stop being so picky.
We could make the class names special or add some attribute to the classes so that we can automatically recognise if they should be imported. If this gets accepted, I will make another pull request with support for filters as well. |
I added dynamic imports for filters and rules as well. The code is virtually the same as the applications. |
I'm still thinking about ways to make CCR imports fully dynamic. |
To get the modules, we could just check for subdirectories of ccr and find all the Python modules inside. Since those modules will potentially contain classes which should not be imported and given global names, we could try one of the approaches below: 1.We could create a list in every ccr grammar which would contain the names of the classes which must be imported. 2.An attribute could be added to the 3.We could crosscheck the rules which have been added to the merger to know what should be imported. |
I would open up a Issue since this pull request has been merged. |
For the applications, the dynamic importation allows for error checking the application modules. While this is not a perfect solution, since runtime errors from invoking the commands will not stop the crashes, for any debugging purposes this makes testing changes much much easier.
For the ccr, I just added try except blocks because I couldn't figure out a similar solution due to the fact that class names are imported. I am not sure how I could import classes and their names without doing something like setting the globals dictionary which is not a very good idea. I am mostly making this pull request so that I can get some feedback on how to make this solution better.