There’s an emoji library for Python that makes printing an emoji relatively easy. First, import the emojize function from the library, and then call it on the text version of a string containing an emoji. For example:

When it encounters :cat_face:, the emojize function will replace the text with the corresponding emoji, 🐱. The library supports a a full list of emojis that you can use in Python. For this lab, you can get creative with the ones you choose (as long as they’re distinguishable from one another).

For this lab, you’ll use two lists of length 12 to keep track of what’s happening with the cards in the game:

Cards that are "hidden" should be displayed face down. As the user interacts with cards, you can change their status. For example, if the user is in the process of making a turn and they have temporarily flipped a card face up, you can represent the card’s status as "selected". If the user matches two cards, you can set the status of both cards to "matched".

Cards that are selected but not matched will reset to hidden at the end of turn. Cards that are matched stay matched and will remain visible for the remainder of the game.

To complete your memory game, you must write the following functions, and your implementation must match the specifications given here. You may write additional functions if you’d like. You should read the function specifications all the way through and only start programming when you have a good understanding of how main() uses each of the other functions.

build_cards(emojis): This function takes in a list of six emoji strings. You may assume that the argument list will contain unique entries and that it will have exactly six emoji strings in it, This function should ultimately produce and return a list containing six pairs (12 total entries) of randomly shuffled emoji strings.

The general sequence of events for this function is:

The shuffle function from the random library will help you:

After implementing this function, test it with an input list that contains six emoji strings. It should return to you a list containing exactly 12 emoji strings (six matching pairs). For example:

You should see a different (randomized) output each time you run it. Here are some examples:

print_cards(cards, status): This function takes two lists, each with 12 entries. The cards list is the list of emoji strings that was produced by build_cards. The status list is a list of 12 strings containing one of "hidden", "selected", or "matched" as described above in the Representing Cards section.

This function doesn’t return anything or modify either of its input lists. It should print two rows of output based on the contents of the lists.

To create the output for each row, you can take advantage of the fact that both lists are the same length (12 entries) and iterate through every index of both lists to 1) check the status list at that index and then based on its value, either choose to display the corresponding card emoji or the "face down" emoji.

For example, suppose you had the following two lists:

You should expect to see output that looks like:

Rather than trying to neatly separate the emojis and indices using spaces, you can use a single tab character \t in between each entry to cleanly space them out.

For example:

Produces output that looks like:

handle_guess(status): This function takes in a status list of 12 strings, where each string is one of "hidden", "selected", or "matched" as described above. It should prompt the user "Which card would you like to reveal?" and you may assume that the user will enter an integer value. You should NOT assume that the integer will be valid according to the rules of the game, so handle_guess should not proceed until both of the following conditions are met:

After meeting both conditions, handle_guess should set the status of the card at the selected index to "selected" (by mutating the list) and return the selected index number.

If condition 1 isn’t met, you can simply tell the user that their choice is invalid before prompting again.

If condition 2 isn’t met, you should print a message to let them know why.

Supposing you had a status list that looks like:

Here are some examples of what this function’s behavior might look like:

play_one_turn(cards, status, turns): This function takes in a list of cards, a status list, and the number of turns the player has remaining. It’s responsible for playing one round of matching (asking the user to select two cards) and checking to see if the selected cards match. If they do match, it should return True, otherwise it should return False.

The overall sequence of events for this function is:

In the beginning, you should use main to incrementally test your individual helper functions and then gradually build the complete program. The final program should give the user six turns, and it should count the number of matches the user achieves after all of their turns are done. At the end of the game, it should print the final match count and show the final state of the matched cards.

A finished program might have the primary steps in main shown below. Think about how to use the helper functions described above to implement each step. Note that some helper functions may need to be called by other helpers and may not appear in main at all!

Think carefully about how each of your functions should be used. Each of the steps in the main function that we have outlined should only need a few lines of code — the helper functions handle most of the complexity.

Additionally, it is very important that you use incremental development. The outline of main is a good starting point — you should complete one step at a time, thoroughly test it to see if your program works, and only move on after getting it to work. The ninjas and instructors will ask you to backtrack and do incremental development if you do not follow this strategy. If you try to implement the whole program at once, you will waste a lot of time and energy trying to fix your program.

For testing certain functionality, it may be helpful to call functions with hard-coded lists that you define to test specific behavior.

Remember to run handin21 to turn in your lab files! You may run handin21 as many times as you want. Each time it will turn in any new work. We recommend running handin21 after you complete each program or after you complete significant work on any one program.

When you’re done working in the lab, you should log out of the computer you’re using.

First quit any applications you are running, including your vscode editor, the browser and the terminal. Then click on the logout icon ( or ) and choose "log out".

If you plan to leave the lab for just a few minutes, you do not need to log out. It is, however, a good idea to lock your machine while you are gone. You can lock your screen by clicking on the lock icon. PLEASE do not leave a session locked for a long period of time. Power may go out, someone might reboot the machine, etc. You don’t want to lose any work!