In the project writeup for the pokemon assignment, several pokemon's names are spelled wrong (Bulbasoar instead of Bulbasaur, Polywag instead of Poliwag, Ninetails instead of Ninetales, and Charmainder instead of Charmander).

Also in the example print statement, it says

Ash is attacking. Bulbosaur used Bubble and did 20 damage.

despite Bulbasaur being a Grass type and Bubble being a Water type attack.

Finally, this says

2/3 the time they should file. 1/6 of the time they should heal and 1/6 of the time they should switch pokemon.

which I believe should say 2/3 of the time a user should attack.

I can submit a PR with these fixes if I can get access (I'm an upcoming volunteer for the 2019-2020 school year) or I'd be okay with someone else making them.

Point of clarification - I'm assuming that the calendar doesn't advance in this simulation/game until the player chooses one of travel, rest, or hunt. That's not entirely clear from the instructions.

Overview:

"Each day costs you food and health." - Not necessarily. Each day costs you food, but maybe not health, unless one of the random bad events occurs.

Behavior:

"On average, the player's health will randomly decrease twice during a month on any given day."

Please rewrite the above to eliminate ambiguity. As written, it is unclear as to whether "randomly" refers to the amount of the health decrease or its timing. And the overall description of the timing is (IMHO) confusing at best.

Implementation details:

MONTHS_WITH_31_DAYS isn't needed outside the add_day() function, so it shouldn't be global.

In my solution, what you call "select_action" is the main body of the program, a while loop without a function. And it doesn't call add_day() directly. It calls the function for one of the six chosen actions, and some of those call add_day().

Grading:

"Game ends if food runs out, days run out, or health runs out" in the rubric should be:

Game ends if days run out, health runs out, you get there (Oregon), or the player quits.

Your instructions don't mention what to do if food runs out. My solution has health dropping by 1 every time the player tries to travel, rest, or hunt without an existing supply of food. Also, that function prints a warning message to the effect that there is no more food remaining.

Extra Credit:

"Create a random event that occurs randomly once a month ..."

As opposed to a non-random event that occurs randomly once a month?

In Lesson 1.05 (https://tealsk12.gitbooks.io/2nd-semester-introduction-to-computer-science/content/units/1_unit/05_lesson/lesson.html) there are (at least) two places where the text references example buggy code. In each place, it links the anchor to

https://tealsk12.gitbooks.io/2nd-semester-introduction-to-computer-science/content/units/1_unit/05_lesson/code.py

When I click on that link, it doesn't go anywhere -- just keeps me on the same page I'm viewing.

The Do Now has two separate sections which tells the students to type in the same code and answer very similar questions. This should be revised.

Do Now 2.06

2. Open up the console

Type the following code using interactive mode

while True:
    print('a')

3. In your Notebook

Write responses for the following

1. What happens when you run this code?

2. Try using other Boolean expressions instead of True (e.g. 4 > 5 and 9 != 2), and explore what happens.

3. How would you print out something 10 times? What about 100? What about 1,000?

4. Can you remember something from Snap! that might allow that?

4. Open up the console

Type the following code

while True:
    print('a')

5. In your Notebook

continue responses for the following

1. What happens when you run this code?
2. Try using other Boolean expressions instead of True (e.g. 4 > 5 and 9 != 2), and explore what happens.

Lesson 3.04 contains 3 learning objectives that use the illegal verb "understand" and are therefore not assessable by teachers:
Understand that changing a list in a function updates the list outside of the function
Understand that updating variables in a function does not affect the variable outside of the function
Understand global variables

These violate the norms taught in TEALS training and should be replaced. In particular, "understand global variables" is an egregious violation since it is not clear what level of understanding students should be able to demonstrate.

It would be helpful to have an alternate block scheduling option for the curriculum. Adjusting from five days a week to 2-3 days a week longer classes is time consuming: if many people are doing this across the nation, a recommended schedule would be very helpful.

It appears that this Do Now is based more in Python 2.x and not 3.x. In 3.x, keys() returns <class ‘dict_keys’> which is not subscriptable. I believe that using subscripts is the cleanest way to print the 5 most frequent and 5 least frequent words from a sorted dictionary satisfying the bonus portion of the lab. In order to use subscripts, the return value from keys() needs to be cast to a list. I think that it would be helpful to highlight the differences between dict_keys and list in addition to the similarities.

Part 1 section 3 - there is no longer an expression that combines different types, so there is no longer an error message here.

I’ve been pulling all of the definitions (in this lesson: console, interpreter, float, integer, string, expression) and creating a “notes” document. It would be great to have one of these ready to go as a resource for students, perhaps divided out by lesson.

3 data types get defined here, but there is no follow up - for example the next day’s Do Now could be about identifying data types, or coming up with reasons someone might use each one… data types are both mundane and important and not understanding them comes back to bite you much later.

One thing this lab gets at is that the same operator works differently (or doesn’t work) for different data types, and formalizing this could be another place to solidify the class’ understanding of the types.

Finally, I’ve made investigating the % and ** operators an extension for each part of the lab (% appears in part 1, ** in part 2) for those who finish early

All info looks like the same info from the TEALS site, where are the actual solutions to any of the labs? TEALS resources are not as clear and concise as other programs such as code.org. There are missing example solutions and answer keys in just about every unit for second semester as well as APCSA This is very unorganized to say the least.

Part 2 of the Do Now and the instructor's notes use the Python 2 behavior of range (generating a list of values). In Python 3, range no longer returns a list of values.

In the Do Now Students are asked to write down the return value of range(0, len(a)) is. This will probably be confusing to students, as it returns a range object (and not a list as the instructor's notes say).

I suggest that Part 2 be removed entirely or added as a bonus/enrichment (e.g., "What is the return type of range(1, 10)? Did anything surprise you?"). If done as enrichment, it could lead into a discussion about why range doesn't simply return a list of values.

The links for the individual Unit 1, Lesson 1 sub lessons don't open into the actual lessons (they just get you the most general directory of all the units).

The numbering is also confusing. Perhaps we can add a picture of the Unit 1, Lesson 1 menu so that people know where to click on the individual lessons.

Functional Correctness rubic parts add up to 36 instead of 35.

Create Word/PDF versions of labs similar to Intro curriculum

Two problems in this section:
the "cat_twice" function example calls a "print_twice" function which is not defined.

Also, the text says "For example, outside print_twice, there is no such thing as bruce."
"Bruce" is not used or defined anywhere in this section and makes no sense in the text.

I just noticed the link is broken for "Text Monster Game - Example Code" in units/2_unit_08_lesson/lesson.md

The project spec for the Unit 3 project states that "The player's health randomly decreases 2 times during the month." The sample solution gives the player a 2 in 30 chance of falling ill on any given day (so it doesn't guarantee that a player falls ill twice in a month).

I think the ideal solution would be to update the spec to match the sample solution (e.g., "On average, the player's health will randomly decrease twice during a month" and clarify that this means on any given day, the player has a 1 in 15 chance of falling ill). Trying to make the player fall ill exactly twice during a month (as outlined in the spec) might be overly complicated for the current skill level of students.

In the Lab 2.04 handout, the second part has the students create a quiz about going to colleges. In the slides and the starter code, the lab is a quiz about food types.

Too many files in unit #1. Move images and other non-markdown files to an assets folder to clean-up.

Can this be more explicit about why it makes sense to talk about binary at this point in the curriculum? I believe it could use greater context on the why it is included here (both in the curriculum in general and why at the start of Unit 2).

After struggling with usefulness of averaging RGB values to create a new color, I thought of an alternative assignment that demonstrates class attributes with a real world example. They would create a class that has a day name, high temperature, and low temperature. They would write two functions to compute the average high and low temperatures using a list of their class. The output would be a table of each day with high and low temperature with the averages printed below.

I am attaching the code that I wrote to achieve the desired output. Because I do not like type long lists of data, I wrote a function to create a random data set which could be a bonus item.
alternate_py.txt

In the Sign Up Guide pdf found in Lesson 1.01, when you are creating your first Repl.it file the instructions say to search for python3. Searching python3 does not result in a python3 result however, just Python. This may be confusing to students worried about selecting the right language and I would update the screenshot

'run' is listed in the commands list but is not executed in the solution code. I realize it is extra credit. Can it be added to the solution?

In section 1.1 of the associated readings, the division operator (/) is incorrectly explained. In Python 3, the division operator always produces a float, even if both operands are integers (this is different from Python 2). See: https://www.python.org/dev/peps/pep-0238/

The example given is:

>>> minute = 59
>>> minute/60
0

It should read:

>>> minute = 59
>>> minute/60
0.9833333333333333

(Cross posted from discussions forum)

I have some concerns about the Unit 6 project (Guess Who), and curious how other instructors have experienced it. We're scheduled to start it late this week or early next week. I'm looking for a few things:

a) Feedback on my concerns
b) Thoughts on whether/how we should revamp the project

Concerns about the incumbent project:

• The project is too easy. Here's my sample implementation of the Unit 6 project. The whole thing is 15 lines of code, plus 35 lines of data that I just copied in from the Lab handout and reformatted as a dictionary. I don't think I used any advanced techniques, just what we'd expect a clean student solution to look like. It's an OK length for a 1 day lab, maybe stretch it to 2. But there's not nearly enough there for a multi-day project.

• The "flavor-text" rubs me the wrong way. The game is the epitome of objectifying people, and the first attribute it highlights is gender. It doesn't specifically enforce binary gender, but all of the sample persons male or female. I don't have strong opinions on gender politics, but this feels like inviting trouble where it is unnecessary. We could change the target objects to cars, or shoes, or washing machines, or college classes, all of which have multiple properties.

• The program is a poor imitation of the actual game Guess Who. That game involves a physical board that displays all the characters at the start, and lets you ask boolean questions ("Is your person wearing glasses"). Then based on the answer you eliminate some people from contention, flipping over their cards. As the game goes on, you have a visibly shrinking set of candidates. It's not obvious what is a good way to replicate that experience in a text-only interface, and it's hard to allow players to ask open-ended questions like "Does your player look happy?". So it's just not that great a game.

• The data entry part of the project is tedious. The lab provides data for 5 characters in its example, and the rubric says you must have at least 5 characters. The game is pretty boring with only 5, but adding more is a matter of laboriously typing out all the names and attributes of those you wish to add. Some students will bristle at this, but still worse: some students will spend a lot of class time just doing data entry. That's a waste.

Thoughts on whether/how to revamp this. Here are some options:

• We could change the flavor-text, leave it as a 1-2 day lab, then move on to Unit 7 or Unit 8. I'm somewhat inclined to do this. Strawman flavor-text: objects are cars, attributes are manufacturer, number of doors, whether forward collision warning is standard/optional/unavailable, whether engine is gasoline/electric/hybrid. Make up fictional car names and/or manufacturers if need be.

• We could provide a larger data file in comma-separated value format, and ask the students to write code that parses it into the dictionary data structure. In general CSV parsing is a pain because of all the corner cases, but we can provide a data file where the parsing is easy -- splitting the file into lines, split each line on commas. Then they need to build up the dictionary of dictionaries. In the end the game is the same, but you could have more total objects in play, which requires more guesses. This could add a day or two to the project, and it is useful experience to have: basic data processing is a key bit of CS, and understanding that/how real-world data gets in an out of programs is a step the students haven't been exposed to.

• We could re-conceive the game as a Shopping Filter program. Anyone who has tried to shop on line, whether for a winter coat, an instructional course, or a thing to do on the weekend, has undoubtedly encountered the search-and-filter paradigm. You say you want a sweater and the site shows you 176 matching items, with a collection of check-boxes off to the side that let you narrow your search. You can filter by Brand, and select 1 or more allowable values. You can filter by price, by available size, by available color, etc. We could provide the students with a data file of the 176 sweaters and ask them to implement the shopping filters. The user is shown results 1-10 of 176, then asked how they want to filter. They select an attribute, and a list of allowable value (e.g. Color: green, red). The program applies the filters, displays results 1-10 of the ones that satisfy. The program allows the user to add, remove, or edit filters that are applied.
  
  This is both a real-world, familiar application and a more substantive undertaking. I would imagine this could take 4-6 days for the students to complete. They could also find and import their own data files from their favorite domains: athlete stats, movies, pokemon monsters, restaurants, etc. And they could extend it with a "sort-by" feature.
  
  The user interface could be a little tricky, but it's not too hard. We could provide it to them as a scaffolding to let them concentrate on the underlying data structures and processing.

I'm leaning towards doing this for my own class:

1. Change flavor text to the car model domain.
2. Give them a data file with ~30 entries in CSV format.
3. Use fictional car manufacturers and model names.
4. Require them to write code to build up the dictionary from the CSV file.
5. Leave the task as "I just leased a car. Guess what car I'm driving"
6. Plan on 4 days for the Project.

Can anyone share their thoughts on and experience with this Lab/Project?

Thanks,
David

Students are confused as the lab directions refer them to a lab we have never done.

The PDF appears to be correct by not referring to this non-existent lab.
This is from the cloned assignment.
2) Remember the tic-tac-toe board we created in class?

Tic-Tac-Toe

The cloned assignment also has def in the code but that has not been introduced to the students.

There's a broken link for an image file of

(pick random (1) to (10))

in Snap in section 2 of the instructor's notes.

#130 The then was changed to them and did not update the out with corrected count. The new count should be 12.

For lesson 4.05 (debugging, before the Tic-Tac-Toe project). our lesson slides (slide 5, line 2) uses sample code with syntax for dictionary, which is not taught until unit 6. This could be confusing. It would be great to modify this example and just use lists. Thanks!!

def boxes_to_buy(num_needed, sizes):
result = {} <---- here
remaining = num_needed

Unit 3 introduces code contracts, which are a simplified version of docstrings used in real-world code (e.g., Google-style docstrings)

I propose that "Arguments" be used instead of "Inputs" for three reasons:

1. It reinforces language used in the lesson
2. Documentation on python.org (and in third-party modules) uses "argument" or "parameter" instead of "input"
3. It avoids confusion with user input / the input function

Can not find any units in the 2nd semester intro to cs Gitbook.
https://tealsk12.gitbook.io/intro-cs-2/

In section 3 of https://tealsk12.gitbooks.io/2nd-semester-introduction-to-computer-science/content/units/2_unit/05_lesson/lab.html it reads

Create a quiz to help you choose which college you should go to (or another topic of your choice. See Example Below)

There is no related example shown below.

First:
A couple typos. The second question is “What is the difference between the to statements here and Part 3 statements?”, “to” should be “two”.
The sub-titles like “In your Notebook, continue to your answers in your Notebook to the following” for some parts are awkward too.

Second:
Part 3 is confusing because of the ‘dog’ output. I think I understand the point is to compare the 2nd line in parts 3 and 4, with part 3 happening first and students being confused by the ‘dog’ output, then in part 4 the reveal of the correct way to write an or statement.
Great, but this ‘dog’ output is never really explained, and is leaving students confused. Answering the question with the typo is hard when you don’t get the ‘dog’ output.

I think maybe parts 3 and 4 should be merged? Also, this is a really long Do Now (to me), so I made it a Pre-Lab.

As a programmer, I expect the spec to give me an example input/output of gameplay showing what a typical game might look like

The keyword def should not be capitalized. The initialization of name should be indented. It should read:

class Pet(object):
    def __init__(self, name):
        self.name = name

Why is the hyphen getting removed from Sam-I-am in the example? When used in this manner, the character is not punctuation; it is creating a compound word. Some examples of other compound word created by connecting with a hyphen are mother-in-law, over-the-counter, and jack-in-the-box.

Line 1 should read: I am Sam. I am Sam. Sam-I-am.

Line 19 should read: Would you like them with a mouse? Changing then to them changes the most frequent word count.

I found the problem description disorganized. I was scrolling up and down while trying to implement the various methods. For example, the attack descriptions and behavior is scattered throughout the document. I suggest reorganizing so that the class behavior/responsibility in one section and game play is described in another section. This could help them with in designing/describing their final project.

Rather than giving them fresh start code, have them start with their code from the previous the lab. The User/Computer class start could be supplied as a text file that they could copy/paste into their code.

The lab specifies that "Pokemon attacks should be stored using a dictionary from the attack name to a list of [attack's power, attack's accuracy]." I feel that a dictionary like {'power': 60, 'accuracy': 100} is a better data structure and helps to reinforce learning from the previous unit.

Based on my experience in teaching other object-oriented languages, including __str__ and operator overloading with introduction of methods is too much information for a single class period. I suggest breaking it into two separate lessons. A sample for the first Do Now could be:

    def printTime(self):
        time = '{0:02n}:{1:02n}:{2:02n}'
        print(time.format(self.hour, self.minute, self.second))

    def getSeconds(self):
        return self.hour * 3600 + self.minute * 60 + self.second

In the second Do Now, we can show that __str__ is a better way to print the time than from the previous lesson. Sample for the second Do Now could be:

    def __str__(self):
        time = '{0:02n}:{1:02n}:{2:02n}'
        return time.format(self.hour, self.minute, self.second)

    def __add__(self, other):
        sum = self.getSeconds() + other.getSeconds()
        hour = sum // 3600
        minute = (sum % 3600) // 60
        second = sum - hour * 3600 - minute * 60
        return Time(hour, minute, second)

Put slide decks in for Unit 5 that make sense to give consistency from unit to unit.

A common misunderstanding among students that I've noticed is to write code like if animal == 'cat' or 'dog':

I think it would be beneficial to explicitly teach that while syntactically correct code, it does not behave as expected. Here's what I propose:

In Lab 2.03 section 1, add the following two items to what the students are asked to predict and test:

>>> animal = 'mouse'
>>> animal == 'cat' or 'dog'

and

>>> animal = 'mouse'
>>> animal == 'cat' or animal == 'dog'

Revisit the concept in Lesson 2.04. During the lecture/class discussion show the following code:

animal = input("What is your favorite animal?")
if animal == 'cat' or 'dog':
    print("A great pet!")
else:
   print("Good choice")

Give students time to predict the output for various inputs, discuss why the code is buggy, and then fix it together as a class. Before I submit a pull request, I would appreciate some assistance refining the language