Can we standardize and optimize the tools and libraries that are used in teaching Python at NICAR? about pycar

[tommeagher]

The setup issue is not trivial. Even in the reserved classes, people understandably insisted on using their own machines. But as we all know, setting them up can murder the momentum of the class. How can we get people, especially new learners, bootstrapped ahead of time? Should teachers be required to post setup walkthroughs 1 week ahead?

[hbillings]

I support the idea of posting walkthroughs, not only because people can get bootstrapped, but also because those who do use the provided machines are going to need to do some amount of set up on their own computers at home.

[rdmurphy]

I do think you can set up some level of expectation for being pre-setup – I noted in my writeup for the grunt/node course that all attendees were expected to have some experience with the shell, and it went fine. For an advanced course, going in with the expectation they have already installed Python and can follow install instructions seems reasonable.

I think it'd be good for us to prep a write up on setup either way for PyCAR. That way people can go home and get to work (instead of leaving them to their own devices/Googling).

[chrislkeller]

@rdmurphy: Regarding...

Agreed. Even in PyCAR we clash a bit – the first lesson uses urllib.urlretrieve, then the third lesson
uses requests. I was kinda surprised no one in our course asked why it suddenly changed.

My thought process: because this was the first lesson and we were focusing on numbers and strings it made sense to use modules provided by the standard library, hence urllib... This avoids explaining the concept of third-party libraries when folks are wrapping their minds around the basic building blocks.

With additional structure we can become consistent, but there's a balance in not overwhelming...

[rdmurphy]

Just want to bring over this email from NICAR-L – I scrubbed the name:

I was about to install virtualenv directly (as in, not in VMWare from the techrake-bootstrap event) and got this warning:

user$ pip install virtualenv

WARNING: using virtualenv with Anaconda is untested and not recommended.
    We suggest using the conda command to create environments instead.
    For more information about creating conda environments, please see:
         http://docs.continuum.io/conda/examples/create.html

Proceed (y/n)?

Here’s my major concern. I am trying not to clutter up the hard drive on my MacBook Pro because I don’t want to crash it.

A couple of you noted the VM installation on top of Mac’s native Python and said it was unnecessary. I also found three Python installations on my machine BEFORE NICAR15.

I installed Anaconda as part of the Python 1-2-3 workshops.

I’m not sure at this point what to keep, what to jettison, whether the VM environment is redundant or a good precaution.

Opinions welcome. We can take it off-list to save others the hassle. Thanks again to all who are offering help!

I feel like this is the sort of confusion we want to avoid. Beginners are receiving conflicting information from multiple courses and being left asking, "what's actually the right way to do this?"

As we continue these discussions, I think it would be good to re-evaluate the use of things like Anaconda in an introductory teaching environment, especially when we are having people do initial setups with it on their computers.

Many tutorials/libraries/guides assume you're doing things the "normal" pip/virtualenv/virtualenvwrapper way – if people potentially only get taught conda I worry we're leaving them in a bind.

[esagara]

I tend to lean toward picking a version of Python - ie 2.7 - and starting out with nothing but a clean install. Here's why:

We are skipping steps

Moving from urllib in Project 1 to Requests in Project 3 (I was actually surprised to see this jump - even though I was the one who wrote Project 3 without looking at Project 1) makes sense if we are teaching the students the difference between modules already in the standard library versus ones you have to import. There is the potential for frustration when students go home and realize they do not have Requests installed because we do not cover how to install a third party library. We don't teach pip or easy_install and we do not teach them what to do when pip is not available. This can be a big barrier for a new programmer to overcome. I remember being very frustrated when I had to spend time searching the Internet to overcome these issues when I came home from my first Python class (though the argument could be made that in itself was a good exercise).

We are making decisions for the students

Using a specific distribution of Python is largely a matter of personal preference - just like how we all have different environments we develop in. We should not be extending those preferences onto the students, in many ways those are decisions they should be making themselves. The only preferences we should be imposing on our students is compliance with PEP 8 style (I am actually pretty bad at this myself).

It can be confusing

Even the instructors spend some time adapting to the new environment we are presented with when we try to code on a IRE/NICAR-provided computer. We are able to adapt quickly because we are more experienced and can figure out things faster. Students do not have that luxury.

We can't simulate all the variables when it comes to coding at home

Some students did bring their own laptops, but many did not. We have no idea what they will be facing when on their own at home. We don't know what operating systems or what permissions they will have. Staying with a clean, basic install of Python will be the best we can do to simulate the student's first time coding on their own.

We probably should not be teaching shortcuts

Initially I had supported the idea of getting a standard text editor and figuring out how to configure it ahead of time for the entire class. Now I wonder if that is a good idea. We should have one text editor, but students should have to deal with the frustration of hitting spacebar four times for a while. We do lose time in class constantly playing the game of "find the random tab" constantly, but imagine the time loss and frustration a student will experience when they try to code on their own for the first time.

[tommeagher]

Re: anaconda, I got several questions the last couple days about how to deal with it. I responded to one of the listservs with this;

This may seem odd since I used Anaconda/conda to teach a class the other day, but if I were you, I'd probably uninstall it and use one of the regular Python windows installers instead. Anaconda can be good for teaching, because it includes most of the packages we'd commonly use. But it's a huge distro, and it's really made for data scientists that need all of that. I've used it so we wouldn't have to go down the rabbit hole of virtualenvs and pip when trying to teach the basics. The shortcoming of that approach, I'm realizing, is that it glosses over this key step in the process that then leaves people more confused on Monday when they try to do it at home.

Sounds like many of you are having a similar reaction this week.

[richardsalex]

We've made an attempt to centralize planning of different coding avenues (Python, R, Ruby, JS) by having a couple of volunteers in each help organize "tracks" that range from novice to more intermediate/advanced. One of the central goals here by doing this is to help keep lines of communication open between teachers ahead of the conference while everyone plans there classes — this will also mean (hopefully) that teachers can debate the merits of one library over another for similar tasks and ultimately find a compromise as far as which one to teach.

As far as the right way to do this at home or work, we use Anaconda for conferences primarily because it simplifies the process of having lab computers that are all things to all class attendees — Python and beyond. You've seen the software folders on those machines.

We've discussed going the attendees-bring-their-own-computers route, but there's a huge risk when you're dealing with an extremely limited timeframe in which to teach. Having classes that grind to a halt and go nowhere because of installation problems or because conference-goers didn't install the right thing ahead of time can really pose a problem and undermine everyone's experience.

I guess I'll close by saying an Anaconda installation is never what I'll recommend to someone at home; I'm going to tell them to do a clean Python install (or Homebrew's verson, on a Mac), along with virtualenv and virtualenvwrapper, plus the text editor they decide they like the best.

We're getting together a couple hours of open lab space in Denver where people can seek in-person help on issues like this. More on that to come.