← Back to the Introduction to Computer Science outline The Course Maker
← Introduction to Computer Science outline
Week 3 · Discussion: Traditional alternative (no AI)

Week 3 Discussion — What Should a Program Do With What You Type? — Traditional alternative (no AI)

Introduction to Computer Science Free sample edition
Traditional alternative (no AI), unpublished. In the course this is a separate discussion that ships unpublished beside the adaptive discussion: same objective, no AI. An instructor who prefers it publishes it and unpublishes or deletes the adaptive one, as the note at its top says.

Instructors: publish this instead of the adaptive version if you prefer, and unpublish or delete the adaptive one.

Hook

A café screen fits only 3 letters of your name on a cup, and a sign-up form treats the 25 you typed as two characters of text. This week you learned that a program receives typed input as a string, keeps it exactly as typed, and can cut it into pieces by index and by slice, so every one of those choices was made by someone who wrote the code.

Your discussion question — choose Option A or Option B; they carry the same weight and the same rubric, and you say which you picked.

Option A: Many systems shorten a name or a title with a fixed slice: a cup label, a badge, a receipt line, a bus sign. Describe one you have seen or can imagine, say which slice would produce it, and decide when cutting text to a fixed length is a fair design choice and when it does real harm to the person whose name gets cut. Use this week's ideas (a string, an index, a slice, len(), and the IndexError a strict index can raise) and say what someone who weighs space differently from you would argue.

Option B: Every value that input() hands back is a string, so a program can either accept what a person types and convert it carefully, or refuse anything that is not typed exactly the expected way. Take a position on how strict a form or app should be about what people type, such as an age, a quantity, or a page count, and decide who should carry the burden when typed text does not fit: the person typing or the person who wrote the program. Use this week's ideas (input(), int(), an f-string, and the TypeError that mixing text and numbers raises) and say what someone who values strictness differently from you would argue.

There is no single right answer. People who agree on every fact about how Python treats strings still disagree about where a program should bend and where it should refuse, because those questions rest on judgment about people as well as on the facts. Pick the option you actually care about, and make your case.

Expectations

Activity format: one initial post followed by two substantive peer replies. Plan on about 45 minutes across the two deadlines; your instructor sets both due dates in Canvas.

Your initial post — by the first due date (early in the module week):

  • Say which option you chose.
  • For Option A, describe the system, write the slice that would produce its shortened text, and say when a fixed cut is fair and when it harms someone; for Option B, say how strict a program should be about typed input and who should carry the burden when it does not fit, with a reason or an example.
  • Use at least two of this week's terms (string, input(), int(), index, slice, len(), IndexError, TypeError) correctly.
  • State the strongest case for a view you do not hold, in one or two sentences.
  • Length: roughly 150–250 words if written. You may instead record your post as audio or video (about two minutes) and attach a transcript; both forms are scored by the same rubric.

Your replies — by the second due date (the end of the module week):

  • Reply substantively to at least two classmates.
  • A substantive reply does more than agree: test their slice on a name of a different length, point out a typed value their rule would mishandle, or make the strongest fair case for the side they did not take. "Nice point!" on its own does not count.

What a strong post looks like:

I chose Option A. A gym's printed badge keeps only the first 8 characters of a member's name, which is the slice name[:8]. For a short name the slice is harmless, because a slice past the end stops quietly instead of raising an IndexError. For a long name it cuts the person off partway, and a badge that reads as a different word can embarrass someone at the front desk. I think a fixed cut is fair only when the program also shows the full name somewhere the person sees it. Someone could argue the badge really has room for 8 characters and nothing more, and that is fair for the badge itself, but the program can still keep the whole string.

Notice how it names the exact slice, says what happens for short and long names, takes a position, and states a fair case for the other side. That is the bar.

Participation rubric

This discussion is worth 10 points. The three criteria below look at your initial post and your peer replies.

How the 10 points of this discussion are earned
Criterion Full credit Partial credit No credit
Quality of the initial post (4 pts) A specific system or typed value, with the exact slice or conversion named, a clear position with a reason, and a fair statement of another view A case is present, but the slice or conversion stays vague, or the position is asserted without a reason Missing, off-topic, or no reasoning about typed text or shortened text
Use of course concepts (3 pts) Uses string, input(), int(), index, slice, and the error types precisely, with every term applied correctly Uses a term loosely, or treats typed digits as a number No course terms, or used incorrectly
Engagement with peers (3 pts) Two or more substantive replies that extend or challenge a classmate's reasoning One substantive reply, or replies that only agree No replies, or "I agree" with nothing added

Post early if you can — the best threads happen when people have time to reply before the second due date.

Built with The Course Maker · samples.thecoursemaker.com