I almost titled this “I hate ‘input’ and ‘print'” but that’s not really true.
I’m teaching a course called “Introduction to Computational Data Science” this semester, just like I did last spring, and even with only two days under my belt I’m reminded how much I struggle with ‘input’ and ‘print’ commands. I think it has to do with the years I’ve spent programming Mathematica but using Jupyter and/or Colab feel quite similar.
So what am I referring to? The first assignment in this class (which has a programming class as a prerequisite) is for the students to make a video walking me through a python function they’ve made that takes an value and returns a list that’s dependent on whether the value is even or odd. It’s also supposed to throw an error if the value is not an integer. It’s really a quick test of their programming ability, and it lets me diagnose things quickly for those who might need a little help.
What’s the big deal, right? Well, nearly all the students do something like this:
def myFunc(): x=int(input("please give me a number, you wonderful stranger")) if x%2: for i in range(x//2+1): print(i) else: for i in range(3*x): print(i)
Why, you may ask? Because that’s how a lot of their text last semester encouraged them to do things and even the text I’m using, which has a lot of basic python chapters that I only use as reference, basically encourages that sort of function.
But I hate it! Ok, that’s, again, too strong. But I do have some problems with it, and it has to do with who the audience is.
Often in introductory programming courses you’re encouraged to think about a fictional client that you’re writing code for. Hence the “you wonderful stranger” joke above. And for clients like that, printing nice messages or values is quite a reasonable thing to do (hence the ‘print’ commands).
But for computational data work, my audience is often (always?), well, me! For me, just making a function that takes an argument and then later calling it with whatever argument I want works just fine:
def myFuncForMe(x): if type(x) != int: return  if x%2==0: return [x**2 for i in range(x//2+1)] else: return [x**3 for i in range(3*x)] myFuncforMe(2)
Lots to unpack there:
- The function takes an argument instead of relying on “input”. That means that it can be used in a larger program
- The function always returns a list, though if it’s not an integer it’s an empty list. This should help it fit into larger program
- No print statements! This is a workhorse little function that can be called a bunch of times and it won’t clutter up your workspace.
- Beautiful list comprehensions instead of clunky for loops. Often if I’m looping through something I’m creating a new list and that’s what list comprehensions are built for
So if you’re slowly building a tool set that might let you gather and analyze big data, I don’t think you should be using “input” or “print” commands, at least not very much. They’re for debugging, sure, but if you’re using Jupyter or Colab, just start a new line of code to check stuff. Plus if you’re using those you can tell the story of what your code is doing so much better than if you use Spyder or some other IDE.
Ok, rant over. Your thoughts? Here’s some starters for you:
- I’m in this class right now and I need to go back and change my homework submission.
- I’m in this class right now and I need to know how I drop.
- I like this. While we’re at it, let’s try to keep students from using . . .
- I hate this. Don’t you realize how powerful “input” and “print” are?! For example . . .
- I like the two-audiences approach you’re taking. What I would add is . . .
- If you’re not writing code for someone else to use you can’t call yourself a programmer.
- If you’re writing code for someone else to use you can’t call yourself a programmer.
- I love Jupyter/Colab for these reasons and more . . .
- I turned my homework in last night and I assumed you’d be grading it instead of writing this drivel