Learn AI-Assisted Python Programming

LEO PORTER DANIEL ZINGARO

Dan thanks his wife, Doyali, for trading some of their time, again, to help this book exist.

Leo thanks his wife, Lori, and his children Sam and Avery for their love and support.

Contents

• Foreword
• Acknowledgments
• Introduction

2. Variables

• 3. Conditionals

• 4. Strings

• 5. Lists

• Conclusion
• Summary

Reading Python code: Part 2

Chapter 5: Top 10 programming features you need to know: Part 2

6. Loops

7. Indentation

8. Dictionaries

9. Files

10. Modules

Summary

Chapter 6: Testing and prompt engineering

6.1 Why it is crucial to test code

6.2 Closed-box and open-box testing

Closed-box testing

How do we know which test cases to use?

Open-box testing

6.3 How to test your code

Testing using the Python prompt

Testing in your Python file (we won’t be doing it this way)

doctest

6.4 Revisiting the cycle of designing functions with Copilot

6.5 Full testing example

Finding the most students we can add to a row

Improving the prompt to find a better solution

Testing the new solution

6.6 Another full testing example—Testing with files

What tests should we run?

Creating the function

Testing the function

Common challenges with doctest

Summary

Chapter 7: Problem decomposition

7.1 Problem decomposition

7.2 Small examples of top-down design

7.3 Authorship identification

7.4 Authorship identification using top-down design

7.5 Breaking down the process subproblem

Figuring out the signature for the mystery book

7.6 Summary of our top-down design

7.7 Implementing our functions

• clean_word
• average_word_length
• different_to_total
• exactly_once_to_total
• split_string
• get_sentences
• average_sentence_length
• get_phrases
• average_sentence_complexity
• make_signature
• get_all_signatures
• get_score
• lowest_score
• process_data
• make_guess

7.8 Going further

Summary

8 Debugging and better understanding your code

8.1 What causes errors (bugs)?

8.2 How to find the bug

• Using print statements to learn about the code behavior
• Using VS Code’s debugger to learn about the code behavior

8.3 How to fix a bug (once found)

• Asking Copilot to fix your bug via chat
• Giving Copilot a new prompt for the whole function
• Giving Copilot a targeted prompt for part of a function
• Modifying the code to fix the bug yourself

8.4 Modifying our workflow in light of our new skills

8.5 Applying our debugging skills to a new problem

8.6 Using the debugger to better understand code

8.7 A caution about debugging

Summary

9 Automating tedious tasks

9.1 Why programmers make tools

9.2 How to use Copilot to write tools

9.3 Example 1: Cleaning up email text

• Conversing with Copilot
• Writing the tool to clean up email

9.4 Example 2: Adding cover pages to PDF files

• Conversing with Copilot
• Writing the tool

9.5 Example 3: Merging phone picture libraries

• Conversing with Copilot
• Top-down design
• Writing the tool

Summary

10 Making some games

10.1 Game programs

10.2 Adding randomness

10.3 Example 1: Bulls and Cows

• How the game works
• Top-down design
• Parameters and return types
• Implementing our functions
• Adding a graphical interface for Bulls and Cows

10.4 Example 2: Bogart

• How the game works
• Top-down design
• Implementing our functions

Summary

11 Future directions

11.1 Prompt patterns

• Flipped interaction pattern
• Persona pattern

11.2 Limitations and future directions

• Where Copilot (currently) struggles
• Is Copilot a new programming language?

Summary

References

Index

Foreword

It’s an awesome time to learn programming. Why? Let me use an analogy to explain.

I like to make my own bread. I make it more frequently, and more reliably, when I use my stand mixer to knead the dough compared to kneading it by hand. Maybe you’d say that’s lazy. I’d say it makes me more productive and more likely to actually make the bread. Maybe you have something that makes your life easier by taking over a tedious task, leaving you free to focus on more important or interesting things. Do you have a car that supports you in parallel parking? I recall when Gmail added spell and grammar checks in languages other than English. My husband’s German relative were so excited that he was writing them longer emails—because the effort of remembering little-used German language specifics went away and allowed him to spend more time on the content!

Sadly, until recently, when learning programming, you had no equivalent of a stand mixer or grammar check to support you. And there are lots of tedious things to learn and remember when you start programming.

Good news! As of spring 2023, radically new and (we think) effective support is finally here. You are about to learn programming with one of the most exciting human task supporters so far this century: artificial intelligence. Specifically, this book seeks to support you in developing your ability to program in Python to solve computational problems more easily and faster by teaching you using a tool called GitHub Copilot. Copilot is a programming support tool that uses something called a LLM (large language model) to draw “help” from

Foreword

a huge number of previously written programs. Once you learn how to direct it (sadly, it’s more complicated than effectively using a stand mixer), Copilot can dramatically increase your productivity and success in writing programs to solve your problem.

But should you use Copilot? Are you really learning to program if you use it? Preliminary evidence looks positive—showing that students who learned with Copilot, when assigned a programming task to be done without the help of Copilot, did better than students who learned without Copilot (and also did the task without Copilot) [1]. That said, compared to what we used to teach in an introductory programming class, there are different skills you will need to focus on when programming with Copilot, specifically problem decomposition and debugging (it’s OK if you don’t know what those are). Just know, practicing programmers need to know those skills as well, but we previously weren’t able to teach them explicitly or effectively in introductory courses, because students didn’t have the brain space left for learning these “high-level skills” while focusing on nit-picky things like spelling and grammar (programming languages have these, just like real world languages).

Leo and Dan are expert computing educators and researchers; the decisions that they’ve made to guide your learning in this book are grounded in what we know about teaching and learning programming. I’m excited that, with this book, they’re taking steps toward what the next wave of teaching programming will look like.

So, congratulations! Whether you have never done any programming or whether you started to learn before and got frustrated… we think you will find learning to program with Copilot transformative and will allow you to engage your brain in more meaningful and “expert-like” programming experiences!

—Beth Simon, Ph.D.

Acknowledgments

In particular, we thank our Development Editor Rebecca Johnson for her expertise, wisdom, and support.

Rebecca provided insightful feedback, constructive criticism, and creative suggestions that have greatly improved the quality and clarity of our work. Rebecca was supportive and encouraging and helped us manage book timelines and our busy schedules. Thank you, Rebecca—you went above and beyond for us.

We also thank our Technical Editor Peter Morgan and our Technical Proofreader Mark Thomas. Both offered valuable contributions to the quality of the book.

To all the reviewers: Aishvarya Verma, Andrew Freed, Andy Wiesendanger, Beth Simon, Brent Honadel, Cairo Cananea, Frank Thomas-Hockey, Ganesh Falak, Ganesh Swaminathan, Georgerobert Freeman, Hariskumar Panakmal, Hendrica van Emde Boas, Ildar Akhmetov, Jean-Baptiste Bang Nteme, Kalai C. E. Nathan, Max Fowler, Maya Lea-Langton, Mikael Dautrey, Monica Popa, Natasha Chong, Ozren Harlovic, Pedro Antonio Ibarra Facio, Radhakrishna Anil, Snehal Bobade, Srihari Sridharan, Tan Wee, Tony Holdroyd, Wei Luo, Wondi Wolde, your suggestions helped make this a better book.

We thank our colleagues for supporting our work and offering their ideas for what such a book should attempt to do. Many of their ideas have informed our thinking as we sought to redefine what an introductory programming course looks like. We particularly thank Brett Becker, Michelle Craig, Paul Denny, Bill Griswold, Philip Guo, and Gerald Soosai Raj.