This course evaluates your progress with practical Python work. The focus is on learning to solve small problems, test your code, and explain your thinking.
This page gives a general course-level overview. Your instructor may provide more specific grading details for each assignment.
This sample, not a mandatory course policy, gives instructors a starting point for an existing guided lab or mini project. Your instructor must publish the rubric, assignment weights, deadlines, and revision rules they actually use. These points are for one assignment, not percentages of your final course grade.
| Criterion | Full evidence | Developing evidence | No evidence yet |
|---|---|---|---|
| Completion: 4 points | 4: All assigned sections are attempted and easy to locate. | 2: Some assigned sections are attempted; others are missing. | 0: No required work is available to review. |
| Code behavior: 6 points | 6: The requested concepts and behavior work for the assigned cases. | 3: The approach uses relevant concepts but has an error or missing behavior. | 0: No relevant code or reasoning about its behavior is shown. |
| Testing and revision: 6 points | 6: Requested tests compare expected and actual results; required debugging notes explain a change or test. | 3: A useful test or revision is shown, but results or reasoning are incomplete. | 0: No testing or revision evidence is shown. |
| Explanation: 4 points | 4: Clear, specific explanations in your own words connect the code to its purpose. | 2: Some accurate explanation is present, but important steps remain unclear. | 0: No explanation of your own understanding is shown. |
Total: 20 points. In this example, code behavior and testing each carry 30%; completion and explanation each carry 20%. They are not weighted equally. The instructor may adapt these weights before assigning work. For a reflection-only activity, use a short completion/feedback approach instead of this code rubric.
Completion rewards an attempt at each required section; it does not mean the answers are correct. Score the quality of code, tests, and explanations in their own rows. Do not automatically deduct from every row because one line has an error. For deliberately broken demonstration cells, assess the requested prediction or explanation, not whether the original example runs successfully.
A learner completes all sections (4), has a condition error (3), records a useful test but does not explain its result fully (3), and clearly explains the intended behavior (4). Under this sample rubric, the result is 14/20, not zero. Feedback identifies the condition and test explanation to revisit.
A program that produces correct output can still need more evidence of testing or understanding. Conversely, a documented mistake can show useful learning even before it is fixed. Apply academic-integrity concerns through the published course policy, not by guessing from a score.
For the final project, Notebook 12 remains the authoritative specification, including a normal-case test, an edge-case test, a Fix Log, and reflection. This rubric adds no project features. If no error occurred, the Fix Log can explain a change or test and what you learned; do not invent an error.
An instructor may adopt this example: allow one revision within seven days of feedback, with a short note describing what changed, a rerun of the relevant tests, and an updated explanation. Re-score the revised evidence using the same rubric, without a revision penalty. Publish any end-of-term cutoff and late-work rules in advance.
This is not an automatic entitlement to resubmit. Check your instructor's policy. An instructor who does not offer re-review should say so explicitly. Revisions replace the earlier work; they are not a new assignment.
Instructors usually look for evidence of:
- completion of required tasks
- code that follows the assignment directions
- correct or reasonable output
- clear use of Python basics taught in the course
- effort to test and revise your work
- explanations that show your own understanding
- care with file names, instructions, and submission requirements
You are not expected to write advanced or professional software. You are expected to practice carefully and show what you understand.
Correctness means your code does what the task asks it to do.
For beginner assignments, this may include:
- using the correct variables or values
- calculating a total or average correctly
- writing an
ifstatement that checks the right condition - using a loop to process each item in a list
- processing each value in a small list correctly
Small mistakes can happen. One error should not automatically erase the value of the rest of your work.
Completion means you attempted all required parts of the assignment.
This includes code cells, written answers, reflections, fix logs, or explanation prompts when they are required. Blank required sections make it harder to see what you learned.
Understanding matters more than complexity. A short solution that you can explain is better than a complicated solution that you do not understand.
You may be asked to explain:
- what your code does
- why you chose a condition or loop
- what an error meant and how you fixed it
- how you tested your answer
- what you would try next if the code did not work
Debugging means finding and fixing problems in code. Testing means running code and checking whether the result makes sense.
In this course, debugging and testing are part of the learning process. Assignments may give credit for showing that you:
- read an error message
- tried a reasonable fix
- tested with a small example
- revised your code after seeing unexpected output
- explained what changed
Following directions is part of professional and academic work. Read assignment instructions carefully before submitting.
Check for:
- required file names or formats
- required notebook sections
- specific starter values or examples to use
- reflection or explanation prompts
- limits on AI assistance or outside help
Grading is not only about whether code is perfect. It is also about whether your work shows practice, care, and growing understanding.
Aim for code that is:
- simple
- readable
- tested
- connected to the task
- explainable in your own words