Initial Major Restructure

[acbart]

Here's what I propose for the directory layout (based on advice by http://docs.python-guide.org/en/latest/writing/structure/):

Top-Level:

• tests/
• docs/
• pedal/
• README.rst
• LICENSE
• MAKEFILE
• requirements.txt
• setup.py

All tests will go in the tests/ directory. We're already using unittest, so we can keep using that. I'll set up the MAKEFILE to run the relevant tests conveniently. I'll also be setting up a code coverage reporter.

We should probably use Sphinx to generate our documentation. I'm going to vote for Google style docstrings - I've been using them in Tifa and I think they're a bit more concise than the regular Sphinx ones. https://pythonhosted.org/an_example_pypi_project/sphinx.html#function-definitions

The Pedal module will have the following submodules:

• cait/: AST matching and code configuration
• tifa/: Type inferencing, flow analysis
• environments/: Compatibility interfaces for BlockPy, Jupyter Notebooks, Web-CAT, etc. I'm not entirely clear what exactly goes in here, but one example is the Magic stuff for Jupyter Notebooks (but maybe that'll end up being distributed across other modules).
• feedback/: The logic from feedback.js that takes all the reports and dispatches them.
• mistakes/: Your collected mistake identifications (formerly the instructor_* pattern groups)
• report/: The functions for triggering feedback strings (e.g., explain, gently, set_success)
• sandbox/: A module for safely executing student code and checking the result.

These should be organized with absolute imports. The __init__.py file in each module should expose the client-facing functions/variables/classes.

Let me know if you have a preferred name for mistakes/ - perhaps misconceptions/ is better for that.

Here's a rough outline of dependencies between these libraries:

• Report can be used by
• TIFA, Sandbox can be used by
• CAIT can be used by
• Mistakes can be used by
• Feedback, Environments

[lukesg08]

All of what you said looks fine to me. I'm not sure I understand the "The init.py file in each module should expose the client-facing functions/variables/classes." because I'm not very well versed in python, but my understanding is that it's used for pathing?

[acbart]

Yep, just a matter of making imports prettier. if you put stuff into init.py, those things are available when you import the module. You can get some more info here.

After some design, I think there needs to be one more aspect to our pipeline: setting the source. This is the entry point for most of the modules, since they all need access to the students' source code. There might be some other elements that need to be set via the environment, but I think this is the primary. Others include:

• Initial results of running students' code (output, variables, etc. a la Sandbox)
• Student usage patterns (how long they've been in the app, when they last took a break, etc.) that could be used for more metacognitive feedback ("Have you taken a break lately?")
• Previous feedback delivered

[acbart]

Anyway, I have a design in mind, I'm going to mock it out and you can see what you think.