COMP 170 Introduction to Object-Oriented Programming

COMP 170 Introduction to Object-Oriented Programming#

This is the starting point for most students interested in learning how to program at a professional level. The course is the first in a sequence of several courses that develop professional-grade programming skills.

The course covers Python programming from first principles along three parallel tracks: programming concepts (following Think Python by Allen Downey), Unix command-line tools and environment (following The Linux Command Line by William Shotts), and mathematical foundations — logic, functions, sets, and introductory algorithm analysis — drawn from course notes. By the end of the course students write multi-class Python programs with docstrings and assertion-based tests, navigate the command line fluently, and can connect programming constructs to the discrete-math ideas behind them.

Course organization and logistics#

Course outline#

Using Python, the course integrates three parallel threads: programming concepts, Unix command-line tools, and mathematical foundations. Topics progress from running a first script through data types, functions, control flow, lists, file I/O, and object-oriented design, while building fluency with the command line and connecting each programming construct to the discrete-math idea behind it.

Deadlines#

:ref

Deadlines are posted on the cource’s Sakai page. In general, late homework is not accepted. Bona fide emergencies are handled on a case-by-case basis. However, if you miss three or more assignment deadlines, you may find it difficult to finish the course with a qualifying grade.

Exam dates#

The final and midterm exams will be take-home assignments. Exact dates will be posted on Sakai.

Textbooks#

All course materials are free and open:

Computer Equipment#

You will need access to a desktop or laptop computer running Linux, macOS, or Windows with WSL2 enabled. Consult the course’s Sakai site for setup instructions.

Attendance policy: attendance is required#

Everyone is expected to miss a class meeting now and then. Missing more than 10% of the class meetings in a term will have a serious impact on your final grade. Missing more, will have a detrimental impact. Coming to class 5 or more minutes late or leaving 5 or more minutes before class is dismissed counts as a missed class.

If you miss a class meeting, it is your responsibility to recover notes and other information from your classmates. Student hours (aka office hours) are not a substitute for missed class meetings.

If you miss more than 1/4 of the class meetings, you final grade will be an F.

The university classifies certain absences as excused (see Undergraduate Attendance Policy). These excused absences do not count as absences in the class. I always appreciate a heads-up if you’re unable to make it to class—it’s helpful and courteous. Please keep in mind, though, that letting me know does not change how an absence is classified under the policy.

Attendance is taken on random days, usually 15 minutes after the start of the class.

I want to be clear about intent here: this policy is not meant to be insensitive to the very real circumstances that can make attending class difficult at times. Life happens, and I understand that. However, as an instructor, I also have a responsibility to determine how much class time can reasonably be missed without undermining the overall educational experience. My determination is about 10% of class meetings, which works out to roughly five sessions for a typical MWF course.

A question that comes up often is:* why can’t I just complete the assignments instead?* The short answer is that doing so would effectively turn the course into a correspondence class. Regular, in-person engagement is a core part of what distinguishes a university education and is tied directly to accreditation standards and the institution’s mission.

If you’re experiencing ongoing difficulties that may affect your attendance, please don’t hesitate to reach out sooner rather than later. I’m always available to talk and help you think through your options.

Attendance for online courses#

In addition to the attendance policy above, online courses have two more requirements.

  • You must join the online meeting from a laptop or a desktop computer. Using tablets in a programming course is marginal; using a smart phone is out of the question.

  • During the class meeting your camera must be on and you must be on camera.

Ungrading and how it works#

Ungrading is a low-stress approach to evaluating progress through a course.

We are accustomed to the traditional method of grading, where assignments are returned with a numeric score or letter grade, but the feedback may not be sufficient to understand areas of improvement. Additionally, we are penalized for our mistakes, despite the fact that they are an essential part of the learning process.

Ungrading emphasizes on feedback that is aimed at helping students improve. Each assignment is viewed as a learning opportunity, where students can reflect on what they did well, and what needs to be improved. Feedback received helps students identify areas of strength and areas that require more work. Progress is tracked by evaluating how well the feedback has been incorporated into the work, and this progress is used to determine a course grade that the student feels they have earned.

The final course grade is ultimately the responsibility of the instructor, however, students are expected to provide their own self-evaluation by proposing their own grade. This is done by writing a brief reflection statement at midterm and near the end of the term, taking into account the feedback received and the extent to which it was incorporated into the work. Based on their own assessment, students will propose a letter grade (A, B, C, or D). This proposal will be considered by the instructor when determining the final course grade.

An effective way to show that feedback has been taken into account is by avoiding recurring issues. These issues can be technical or non-technical in nature. Technical issues are easily recognizable such as writing methods with multiple returns and being asked to reduce them to a single return statement. If the student continues to make the same mistakes, it suggests that the feedback was not effectively incorporated. If there is a valid reason for disregarding feedback, it should be discussed with the instructor.

In general, technical issues are based on requirements, specifications, etc. Soft issues may be more challenging: skipping assignment, turning assignments late, not attending class meetings, not reaching out for assistance, etc.

As a teacher, I have found that most students have a good understanding of their own performance in a course. Ungrading allows me to collaborate with students in articulating their sense of learning, recognizing the skills they have developed, and identifying areas that require more focus and effort to improve.

Reflection statements#

For the midterm and end-of-term reflections statements, I use Jesse Stommel’s suggestions with some additional questions.

Midterm reflection#

  • What aspects of the course have been the most successful for you so far?

  • What thing that you’ve learned are you most excited about?

  • What challenges have you encountered?

  • Can you suggest one or two areas that it may be worth focusing/improving?

  • Based on your performance so far, what do you feel your course grade should be? Choose from A, B, C, or D.

End-of-term reflection#

  • Write me a short letter that reflects on your work in this class.

  • Consider the work you did on exams, assignments, and lab/studio sessions, the feedback you gave and received, and how you met your own goals.

  • Feel free to include examples of your work as necessary.

  • Did you miss any significant work?

  • Is there anything you are particularly proud of?

  • If, in the midterm reflection, you identified any areas for improvement/focus, how did you do?

  • What letter grade would you give yourself in this course? Choose from A, B, C, or D. (Ideally, I would give everyone the grade they give themselves, but I reserve the right to raise or lower grades as appropriate. Also notice that the grade you propose (A,B,C,D) is a range. The actual grade may vary slightly. For example, you may propose a B but end up with an A-. Or you may propose a B and earn a B-.)

Frequently Asked Questions about Ungrading#

What is the grade I see in Sakai? Everytime you submit an assignment, you will earn 1 point. This is not the score of the assignment. This is just Sakai’s way of keeping track who submitted an assignment. Whether your assignment is spot on or off the mark, you will earn 1 point for submitting it. These points do not translate to a score that determines a course grade.

Is there a grade scale? Yes. Students that do not repeat mistakes, usually finish with an A or an A-. Students that require 1-2 reminders for the same mistakes may end the course with a grade in the B range. Students that require more frequent feedback for repeating mistakes but do finally move on, will end the course with a grade in the C range. Students that do not incorporate the feedback will probably finish the course with a D. Rarely, a student may finish the course with an F. I try to avoid this grade; if I feel that you are heading towards an F, I’ll reach out to you to discuss improvement or alternative plans.

Will there be make-up assignments? Every assignment is a make-up assignment: an opportunity to improve on issues that were identified in previous assignments. There will be no extra assignments, however.

I still see homework grades in Sakai, what’s up with this? These are not really grades. You get 1 point in Sakai for each assignment you submit. That’s really a counter of how many assignments you turned in, not actual evaluative score.

Why? Ungrading is very similar to a job situation. We receive feedback from peers and supervisors. The feedback tells us what we do well and what needs more attention. We use the feedback to meet new challenges, improve our skills, and advance our careers. Ungrading is also less stressful because you do not have to worry about a grade scale. It allows you to focus on learning and it is forgiving with mistakes that are not repeated.)

Ground rules#

In my experience, the single most common cause of poor performance in any course is when students are not proactive. When you are proactive you can recognize and address any issues with your courses, while you have time to do something about it. Learning to be proactive is one of the most valuable skills you can acquire in college.

Here’s how you can be proactive, so you can succeed in this coure.

  • Review homework (or other take-home tests) within 24 hours of assignment. Identify questions that may be challenging. Contact the instructor or seek tutoring to work on these questions. The Department of Computer Science offers tutoring services almost on a daily basis.

  • Partially completed assignments are a warning sign. Compare your solution to the published solution. Try to identify the differences. Speak with the instructor or a tutor if the differences are not clear.

  • Skipped or missed assignments are also a warning sign. In some cases, circumstances beyond your control may force you to miss an assignment. This is understandable. The course is designed in a way that allows you to recover from a few missed assessments. If you miss more than 3 assignments, recovery may not be possible.

  • Come to class and take notes. Form or join a study group comprising fellow students. (Attendance is required).

  • If, for any reason, you need to be absent from class, let me know in advance. I don’t need to know the reason, but I need to know about the duration of your absense. Everyone is expected to miss a class meeting now and then. Missing more than 10% of the class meetings in a term will have a serious impact on your final grade. Missing more, will have a detrimental impact. Coming to class 5 or more minutes late or leaving 5 or more minutes early counts as a missed class.

  • Check your official Loyola email at least daily and absolutely an hour before class meetings.

Student hours (aka office hours)#

Student hours for the current semester are posted on my schedule on Calendly.

You can schedule an appointment with me by finding the best time slot that works for you. If there are no available time slots or if they conflict with your schedule, please notify me, suggest a couple of other time slots that will work for you, and I will do my best to find us time to meet.

Walk-ins are welcome but appointments are highly recommended. Students with an appointment take precedence. My office is in Doyle 207. For online meetings, I use Zoom or Microsoft Teams.

Why “student hours” and not “office hours”? I prefer the term “student hours” because it emphasizes that these hours are dedicated to supporting students, rather than being solely about my availability in an office.

Academic integrity#

Students are expected and encouraged to work together. It is also expected that students will explore the vastness of the internet to discover information, knowledge, and solutions to problems. I consider all that to be part of your learning experience. It is up to you, however, to demonstrate your learning.

In practical terms this means that you should be able to describe in your own words how a piece of code works or how you arrived to a mathematical derivation, etc. Failure to do so will affect your course performance and, ultimately, your grade. It may also raise concerns related to academic integrity. Verbatim use of material obtained from others is considered a violation of the university’s policies for academic integrity.

Please note that if you can search for an answer on the internet, so can your instructor. When it comes to programming, there are several websites with good code examples. These are geeksforgeeks, stackoverflow, etc. You are expected to explore these sites. The code you find there can be extremely useful. It is up to you to turn these websites into a learning experience. How? By internalizing the code that you discover in these sites and adopt for your assignments.

If you employ an AI tool, cite its use and list the prompts you used to derive your work. Work that has been found to be produced by generative AI without citation and listing of prompts, will receive a 0 grade.

Computing, i.e., programming and its foundational topics such as mathematics, is something that is best learned by example. But copying other people’s work alone is not sufficient. We must internalize that work, i.e., we must understand how someone else’s code works, how it does it, and why. Without that internalization, we simply copy someone else’s work. And that is not sufficient to pass a course.

Be cool, like a pro#

In additional to the technical content of the course, there is a professional element to it. The professional element of the course is meant to cultivate your essential work skills (some call them “soft skills”). These skills are highly sought after by employers. Essential skills include communication skills, neatness, punctuality, dependability, ability to work in teams, problem solving skills, etc.

In the context of this course, professionalism and essential skills are as follows.

  • Be clear in your communications. When sending an email, make sure that it has an opening, an objective, and a closing.

  • The opening is a greeting line. “Hey” is never an appropriate opening in professional communications.

  • The objective is the main part of your email. Be precise and concise. For example, instead of writing “may I ask a question”, just ask the question.

  • The closing is a statement as to what you would like the other party to do in response to your message.

  • Be respectful of others’ time. Here’re two examples:

  • Come to meetings (class, student (aka office) hours, study groups, tutoring, etc) prepared. If the meeting is about reviewing your code, make sure that your laptop is sufficiently charged, the computer is turned on, and the code is already loaded into some editor before you even step into the meeting room. Do not spend 5 minutes in the meeting finding a power outlet, turning on and booting the computer, and firing up an editor.

  • Online class meetings are not the place to text the instructor questions related to individual concerns (your grade in a homework assignment etc.) Please do not use class time for such questions.

  • When in group meeting (e.g., class, study group, etc) keep your questions relevant to the objective of the meeting.

  • When making an appointment and you realize that you cannot attend the meeting, notify the other party as soon as possible.

  • When discussing a problem, be prepared to offer suggestions for reasonable solutions.

  • Be respectful of your own time.

  • Try emailing a question instead of waiting for Student (office) Hours. If the question is related to programming, attach a copy of your code. In most cases you will get an answer within a few hours.

  • Read and understand instructions and requirements. They set the expectations for your work. It’s important that you follow them.

  • Be organized and neat.

  • When turning in homework or other assignments, make sure that your writing is legible and the overall appearance reflects quality and care. Content is always the most critical aspect of your work; but appearance counts too.

  • When submitting code, make sure the files are properly named. For example homework.java may make sense on your side of the shop, but from the grader’s perspective it’s not very helpful. Files should be named after the class they contain, and must include comments in the code identifying you as the author.

  • When submitting photos of your work, name the files accordingly. Instead of IMG_123.JPG it should be called JohnDoe_problem1a.jpg or something equally indicative of where the file is coming from and what it contains.

  • Follow instructions. Instructions and directions reflect expectations and requirements for your work. File naming conventions, deadlines, content style, etc, are important aspects of your work both in college and beyond.

  • Check your official Loyola email regularly (at least once a day, and definitely an hour before class).

Formal notices#

  • The university’s official Academic Calendar.

  • Every effort is made in this course to use open source, freely available material. However materials from the course cannot be shared outside the course without the instructor’s written permission.

  • Loyola University provides reasonable accommodations for students with disabilities. Any student requesting accommodations related to a disability or other condition is required to register with Student Accessibility Center (SAC), located in Sullivan Center, Suite 117. Professors receive the accommodation notification from SAC via Accommodate. Students are encouraged to meet with their professor individually in order to discuss their accommodations. All information will remain confidential. Please note that in this class, software may be used to record class lectures in order to provide equal access to students with disabilities. Students approved for this accommodation use recordings for their personal study only and recordings may not be shared with other people or used in any way against the faculty member, other lecturers, or students whose classroom comments are recorded as part of the class activity. Recordings are deleted at the end of the semester. For more information about registering with SAC or questions about accommodations, please contact SAC at 773-508-3700 or SAC@luc.edu.

  • Accommodation letters. Students with accommodation letters from the university’s SAC need to alert me as early as possible in the course. In some of my courses, I conduct weekly in-class assessment instead of homework assignments. Students work on these assessments, during class, for 15-25 minutes. If your accommodation letter entitles you to extended time for testing, I will be happy to make arrangements so that you can return the in-class assessment to me within 24 hours. Please notify me as soon as possible, if you would like extended time fo in-class assessments.

  • Duty to report. Faculty and staff of the University have a mandated responsibility to report any incidents of gender-based misconduct that they are made aware of, even if it happened in the past. Gender-based misconduct includes discrimination based on actual or perceived sex, sexual orientation, gender expression or identity, or pregnancy or parenting status; dating and domestic violence; sexual misconduct (including sexual assault, sexual harassment, and sexual exploitation); and stalking.

  • Statement about online recording. If the course uses software to record class discussions: as a student in this class, your participation in live class discussions will be recorded. These recordings will be made available only to students enrolled in the class, to assist those who cannot attend the live session or to serve as a resource for those who would like to review content that was presented. All recordings will become unavailable to students in the class when the Sakai course is unpublished (i.e. shortly after the course ends, per the Sakai administrative schedule). The use of all video recordings will be in keeping with the University Privacy Statement shown below.

  • Privacy Statement. Assuring privacy among faculty and students engaged in online and face-to-face instructional activities helps promote open and robust conversations and mitigates concerns that comments made within the context of the class will be shared beyond the classroom. As such, recordings of instructional activities occurring in online or face-to-face classes may be used solely for internal class purposes by the faculty member and students registered for the course, and only during the period in which the course is offered. Students will be informed of such recordings by a statement in the syllabus for the course in which they will be recorded. Instructors who wish to make subsequent use of recordings that include student activity may do so only with informed written consent of the students involved or if all student activity is removed from the recording. Recordings including student activity that have been initiated by the instructor may be retained by the instructor only for individual use.

  • Notice of Reporting Obligations for Responsible Campus Partners. As an instructor, I am a Responsible Campus Partner (“RCP”) under Loyola’s Comprehensive Policy and Procedures for Addressing Discrimination, Sexual Misconduct, and Retaliation (available at www.luc.edu/equity). While my goal is for you to be able to engage fully and authentically with our course material through class discussions and written work, I also want to be transparent that as a RCP, I am must notify the Office for Equity & Compliance (“OEC”)/Title IX Coordinator when I have any information about conduct that reasonably may constitute Title IX Sex-Based Discrimination. Title IX Sex-Based Discrimination includes any of the following conduct, when the conduct was within the University’s education program or activity:

    • Discrimination or discriminatory harassment on the basis of sex (including sex stereotypes, sex characteristics, gender identity, sexual orientation, and Pregnancy or Related Conditions),

    • Sexual harassment (including quid pro quo and hostile environment sexual harassment),

    • Sexual assault,

    • Dating and/or domestic violence, and/or

    • Stalking

      As the University’s Title IX office, the OEC coordinates the University’s response to reports and complaints of sexual misconduct (as well as discrimination of any kind) to ensure students’ rights are protected.

      As an instructor, I also have an obligation under Illinois law to report disclosures of or suspected instances of child abuse or neglect (https://www.luc.edu/hr/legal-notices/mandatedreportingofchildabuseandneglect/).

      The University maintains such reporting requirements to ensure that any student who experiences sexual/gender-based violence receives accurate information about available resources and support. Such reports will not generate a report to law enforcement (no student will ever be forced to file a report with the police). Additionally, the University’s resources and supports are available to all students even if a student chooses that they do not want any other action taken. If you have any questions about this policy, you are encouraged to contact the OEC at equity@luc.edu or 773-508-7766.

      If you ever wish to speak with a confidential resource regarding gender-based violence, I encourage you to call The Line at 773-494-3810. The Line is staffed by confidential advocates from 8:30am-5pm M-F and 24 hours on the weekend when school is in session. Advocates can provide support, talk through your options (medical, legal, LUC reporting, safety planning, etc.), and connect you with resources as needed – without generating a report or record with the OEC. More information about The Line can be found at luc.edu/wellness.

  • Use of Appropriate Names and Pronouns. Addressing one another at all times by using one’s chosen modes of address (including preferred names and gender pronouns) honors and affirms individuals of all gender identities and gender expressions. Misgendering and heteronormative language excludes the experiences of individuals whose identities may not fit within a gender binary, and/or who may not identify with the sex they were assigned at birth. If you wish, please share your gender pronouns with me and the class when you introduce yourself, on your name placard, and/or on your Zoom profile. If you do not wish to be called by the name that appears on the class roster or attendance sheet, please let me know privately and I will work diligently to honor your wishes. My goal is to create an affirming environment for all students so that everyone can learn and engage as our full and true selves.

Religious accommodations#

As a Jesuit, Catholic university, Loyola University Chicago invites people of all faiths and traditions to be a part of our community and we are committed to supporting students in their faith journeys. As a faculty members I will make reasonable accommodations for students when the observance of a major religious holiday conflicts with academic responsibilities. If you are unable to attend class, take an exam or quiz, give a presentation, or submit an assignment due to a religious observance, you will be excused and given the opportunity to make up the work.

You remain responsible for all assigned coursework and should notify me in advance via Loyola email about any religious observances that may affect your class participation. Campus Ministry has compiled a list of religious holidays that may impact Loyola students, available on the Campus Ministry website. However, this calendar is advisory– I will make reasonable accommodations for students observing significant holidays, including those not listed.

Inclusion statement#

A university is a place where the universality of the human experience manifests itself. – Albert Einstein

It is my hope and goal to make this course one of your best learning experiences. Computer science courses can sometimes be a bit dry, with little room for variety in perspectives. Nevertheless, there will be opportunities to explore social and cultural aspects of the discipline. The course also offers the opportunity to learn from each other about how we process advanced technical and mathematical concepts. Understanding how different individuals conceptualize and internalize practical and foundational aspects of computing makes us better professionals and colleagues. By respecting the different perspectives, experiences, and worldviews represented in our classroom community, we make the course a space of learning and growth.

As an instructor, I am committed to continue improving this space of learning and growth. This is not something I can do alone. Your feedback and suggestions are essential and wholeheartedly welcome at any time.

The Fall 2026 semester is 15 weeks long, but only 13 of them are technical- content weeks. Week 01 is small-group check-ins rather than full-class sessions — no terminal, no Vim, no Python. Weeks 02–14 are the 13 technical weeks. Week 14 doubles as the capstone week and oral exams. Week 15 is finals: a nominal written exam, with no new content.

Week

Topic

Week 01

Small-group check-ins (no technical content)

Week 02

Reading code, the shell, and your first program

Week 03

Data, types, and git

Week 04

Strings, ASCII, and number systems

Week 05

Loops and pattern-making

Week 06

Conditionals and modular arithmetic

Week 07

Lists, the cumulative pattern, and the first assert

Week 08

Dictionaries, right after lists

Week 09

Splitting strings and writing methods

Week 10

Organizing code across files

Week 11

Accumulators, recursion, reinventing split(), and searching strings

Week 12

Validating input: try/except and the ATM

Week 13

Designing and testing a method, in depth

Week 14

Files, a capstone that reuses the dictionary, and oral exams

Week 15

Finals (no new content)

Fall 2026 — detailed topics#

  • Week 01: Small-group check-ins.

    • No technical content. Logistics that are easier to absorb in a small group: the ungrading scale, the attendance policy, the AI-use policy, how Sakai submissions work — and the expectation that reading closely is the habit this course rewards most.

  • Week 02: Reading code, the shell, and your first program.

    • Two matched recipes (scrambled eggs vs. French omelette) that share every ingredient and step but one, bridged into two Python snippets that share every character but one (print("Hello,", name) vs. print("Hello, name")) — predict the output before running either.

    • pwd, ls, cd, mkdir; Vim’s two modes.

    • python3 file.py, print(), comments.

    • A program as a literal sequence of instructions performed on data; the shell as where every one of them runs this term.

  • Week 03: Data, types, and git.

    • str, int, float, type(), conversion, variables, arithmetic and precedence.

    • The compound-interest program (interest.py → interest_pro.py) as the vehicle for separating input, logic, and output.

    • git init/add/commit/status, introduced at the moment two versions of the same idea already exist. Every assignment from here forward is submitted via git.

  • Week 04: Strings, ASCII, and number systems.

    • ord()/chr(), four anchor values (32, 48, 65, 97).

    • String repetition vs. arithmetic multiplication.

    • Decimal, binary, and hex by hand; drawing shapes with hard-coded prints.

  • Week 05: Loops and pattern-making.

    • for, range().

    • Staircase, triangle, diamond, and bar-chart patterns — discovered from a table of examples first, pseudocode second, loop third.

    • For a triangle of height \(N\), row \(i\) has \(N-i\) spaces and \(i\) stars.

  • Week 06: Conditionals and modular arithmetic.

    • if/elif/else, and/or/not, == vs. =.

    • The modulo operator; the airplane-seating problem.

    • Modular arithmetic: \(n \bmod m\) cycles through \(0, 1, \dots, m-1\).

  • Week 07: Lists, the cumulative pattern, and the first assert.

    • List creation, zero-based indexing, len().

    • The cumulative algorithm (running sum/average): \(\bar{a} = \frac{1}{n}\sum_{i=0}^{n-1} a_i\).

    • New this week: before running a script, write one assert that states what you expect it to do — the seed of the testing habit that later weeks build on.

  • Week 08: Dictionaries, right after lists.

    • dict creation, lookup, in, .items().

    • First use case: counting a small in-memory list of words by hand, then with a dictionary — framed explicitly against “two synchronized lists” as the fragile alternative.

  • Week 09: Splitting strings and writing methods.

    • sentence.split(), the enhanced for loop.

    • Packaging logic into a method with type hints, a docstring, and input validation.

    • Testing habit continues: every method gets a docstring and a one-line assert-based check before it’s considered done.

  • Week 10: Organizing code across files.

    • Running a script directly vs. importing its methods from another file; if __name__ == "__main__":.

    • A module’s namespace as a set of unique names — no two defs can share a name.

  • Week 11: Accumulators, recursion, reinventing split(), and searching strings.

    • Loop-variable naming, the accumulator pattern.

    • Factorial and a first look at recursion (\(n! = n \cdot (n-1)!\), \(0! = 1\)).

    • Reinventing str.split() character by character and debugging the classic consecutive-delimiter bug, including method headers with default parameter values.

    • Writing .find()/.index() from scratch; definite vs. indefinite loops; the multiplication-table nested-loop exercise.

  • Week 12: Validating input: try/except and the ATM.

    • try/except around int(input()); a max_tries cap.

    • Separate if statements (fall-through) vs. elif (mutually exclusive).

    • The retry-loop pattern, organized into withdraw() / attempt_withdrawal() / main().

  • Week 13: Designing and testing a method, in depth.

    • The quadratic formula and discriminant \(b^2-4ac\); complex numbers as (real, imaginary) tuples.

    • Designing solve_quadratic() case by case with a flow chart.

    • Three levels of testing — naive prints, plain assertion functions, unittest — applied to a real, published package.

  • Week 14: Files, a capstone that reuses the dictionary, and oral exams.

    • What a file is, why writes buffer until .close(), the three file modes, reading line by line.

    • Capstone: read a public-domain book from a URL, strip punctuation, and count words — with the dictionary from Week 8.

    • This is also the week before finals: the capstone doubles as the material students are expected to speak to during oral exams.

  • Week 15: Finals.

    • Nominal written exam. Nothing new is taught this week.

Reading material#

All course materials are free and open. The course follows three parallel tracks, each with its own reading:

There is no paid textbook for COMP 170.

Leo’s notes#