just moving code to import and execute python code to a separate directive, not fixing any of the other issues in the runner
Details
added several unit tests, have tested on my local system to make sure that the example tasks still run.
Diff Detail
- Branch
- feature/T76-python-directive-refactor
- Lint
No Linters Available - Unit
No Unit Test Coverage
Generally, this is cool; +1!
I just have a couple pedantic complaints in the source above.
libtaskotron/directives/python_directive.py | ||
---|---|---|
13 | Just a note on terminology. In python, a method is *always* part of a class. If it is not part of a class then it is a function. Is there a particular reason why you are disallowing methods-on-a-class? Could a user do something like this in their task? class MyClass(object): def my_task(self): return 42 my_hidden_object = MyClass() i_want_taskotron_to_execute_this = my_hidden_object.my_task taskotron (I think) doesn't necessarily need to know that i_want_taskotron_to_execute_this is *really* a method on an object, although it is. Similarly, a task writer might provide something like this: class MyTaskClass(object): def __call__(self): return 42 i_want_taskotron_to_execute_this = MyTaskClass() Then, taskotron would try to call i_want_tasktron_to_execute_this and (I think) succeed.. even though that thing is neither a function nor a method. It is a *callable*. I think that's the best choice of language for the PythonDirective docs. Something like
| |
libtaskotron/runner.py | ||
64–65 | There is no need to keep the .keys() call here. The default iterator for a dict just returns the keys. | |
88 | This line seems excessively long. Perhaps break it out for readability? options = {'basedir': basedir, 'method_name': 'run', 'workingdir': self.workdir} exec_output = helper.process(pyfilename, options, {}) |
Thanks for the comments, will update to address concerns raised - especially around the function/method/callable stuff
libtaskotron/directives/python_directive.py | ||
---|---|---|
13 | Thanks for the terminology correction. I was pretty sure that I was being inaccurate but wasn't quite sure what the right terminology was :) The rationale was code simplicity and getting this done since folks are blocked for lack of examples. I didn't want to deal with conditionals on loading a class and then finding a method in that class right now. I wasn't planning on having the 'function only' restriction in the long term. Now that I'm thinking about it, I'm not sure I see a whole lot of functional difference between what's written and what you're proposing. However, I prefer the way you're approaching it (referring to a callable instead of caring about function/method/class) - it's not really more complex and avoids the stated, but not-needed restriction on functions vs. methods. | |
libtaskotron/runner.py | ||
88 | Actually, the entirety of this logic is going away soon (I've already started that refactoring) as it's way too hard-coded but that's no excuse for poor quality code :) |
- changed funcional test names to functest for more differentiation and disabled running of functional tests by default
- changed python directive around to work on callables instead of function names, cleaned up docs and added some tests
- cleaned up some calls, not-needed calls to keys() and updated runner for changes in python directive
I want to get some docs around this code written, so I changed the reviewers/ccs to get going to merge it since it has been reviewed. If anyone who hasn't seen the code yet has concerns about it, please let me know.
Just a note on terminology. In python, a method is *always* part of a class. If it is not part of a class then it is a function.
Is there a particular reason why you are disallowing methods-on-a-class? Could a user do something like this in their task?
taskotron (I think) doesn't necessarily need to know that i_want_taskotron_to_execute_this is *really* a method on an object, although it is.
Similarly, a task writer might provide something like this:
Then, taskotron would try to call i_want_tasktron_to_execute_this and (I think) succeed.. even though that thing is neither a function nor a method. It is a *callable*.
I think that's the best choice of language for the PythonDirective docs. Something like