Summary of Course Entrance Survey
- There is, as expected, a fairly wide range of prior experience with both Python and programming in general. The results were inline with our expectations, and your responses will be useful to us in helping customize the class for you going forward.
- Commonly mentioned learning goals
- gain comfort with coding.
- learn professional software practices (e.g., Github)
- learn how to use external libraries effectively
- spark interest in CS and see if it is for me.
- learn about computation in field X (some X are covered in the course already, some could be the focus of a final project).
- become confident in explaining and communicating about code.
- learn Linux + command line
- write better (neater, more readable, less buggy) code
- team with others on a software project
- get better at asking for help
- Instructor note: not sure on this next one. “i want 2 become a 1337 hax0r”
- Olin second semester students wanted to know how ModSimPy relates to the wider Python ecosystem (NINJAs are already working on a resource to help with this)
Reading Journal Debrief
With two people sitting around you, go over your reading journal. Identify any questions / difficulties and try to work through them. We will do a quick report out for lingering confusions along with observations you’d like to share with the rest of the class.
Modular Design Exercise
In groups of 3, review the solutions from a previous iteration of this class to Chapter 3, Exercise 5, Part A.
What aspects of these different designs:
- Increased / decreased the readability of code (readability means your ability to easily deduce what the code does, how it works, and whether or not it is correct).
- Increased / decreased the flexibility of the code (flexibility means the ability of this code to be easily modified to satisfy new requirements that may aris)e.
In groups, redo Chapter 3 Exercise 5 based on the design that your group decides is most readable and most flexible.
In a surprise move, your manager has asked you to implement two new features for your program.
Write a function that draws the following grid
+ - - - - + - - - - + - - - - + - - - - + - - - - + | | | | | | | | | | | | | | | | | | | | | | | | + - - - - + - - - - + - - - - + - - - - + - - - - + | | | | | | | | | | | | | | | | | | | | | | | | + - - - - + - - - - + - - - - + - - - - + - - - - + | | | | | | | | | | | | | | | | | | | | | | | | + - - - - + - - - - + - - - - + - - - - + - - - - +
Modify your function to take in two additional inputs that specify the dimensions of width and height (in characters) of each of the boxes that compose the grid. For instance,
grid(6, 3) produces
+ - - + - - + - - + - - + - - + | | | | | | | | | | | | + - - + - - + - - + - - + - - + | | | | | | | | | | | | + - - + - - + - - + - - + - - + | | | | | | | | | | | | + - - + - - + - - + - - + - - +
Running Python Code
There are many ways to run the Python code you write:
Method 1: Interactive Python interpreter
$ python3 Python 3.6.3 |Anaconda, Inc.| (default, Oct 13 2017, 12:02:49) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> print("Hello, SoftDes!") Hello, SoftDes!
There is also an advanced implementation of the interpreter called ipython that adds some nice extra features.
Method 2: Jupyter notebooks
This is what you used for the Reading Journal. Each code cell in the notebook is essentially a mini interpreter session.
Method 3: Within IDE/editor
Several integrated development environments/text editors allow you to run Python code as you write it. The mechanism for doing so varies by editor. In order to run Python code from Atom, you should install the “script” package (detailed instructions on installing packages), and then use ctrl-shift-b to execute your code.
A few things to watch out for: when you run code using this method it usually can’t take standard input, so this means you can’t use e.g. the raw_input function. Also, if you run an infinite loop it may freeze your editor!
Method 4: Saved script
Finally, you can save your program as a text file (with a .py extension by convention) and run it at the command line:
$ python3 my_script.py "Hello, SoftDes!"
This is the preferred method for all but the very simplest programs, and is how you will complete all the assignments in this class other than reading journals.
Intro to Unit Testing
Testing our functions interactively in the interpreter as we write them is great for quick tests.
As we move to more advanced functions and programs, we’d like to add several more features. We might want to save the tests, to run them again as our implementation changes. We might even want to write the tests ahead of time, an approach known as test-driven design.
Today, we’ll write our first unit tests. These short tests let us verify each piece of a program independently, which makes it more likely the entire program will be correct once we put everything together. You will be writing more unit tests in mini-project 1, and in all the work you do for this class.
We will be using the doctest Python module, which makes code examples in Python docstrings into unit tests automatically.
Doctests can be run in normal mode, in which only failing tests will be reported, or in verbose mode, which reports results from all tests.
If you’ve written a program called my_prog.py, you can test it from the command line by running
$ python3 -m doctest [-v] my_prog.py
where the [-v] means you can either include the -v verbose flag or not.
You can also run doctests from inside your program, by including:
import doctest doctest.testmod(verbose=True)
at the bottom.
Exercise: Add doctests to your is_triangle function from the Day 1 reading journal and verify your implementation.
Gene Finder (Mini-Project 1) Kickoff
Resources on Protein synthesis