Open jmetz opened 8 years ago
On the other hand, by using the notebook, the students are blocked from simple concepts like importing functions etc. defined in other scripts.
I agree. As much as I appreciate jupyter notebook for teaching APIs, I find that it is always an obstacle for code reuse.
I share your reservations, but this lesson is intended for people who do not have experience with the Unix shell, so my usual combination (nano + run-from-the-command-line) is out. I've experimented with several Python IDEs, and none of them measures up (certainly not to RStudio). What other options do you see?
I've experimented with several Python IDEs, and none of them measures up (certainly not to RStudio). What other options do you see?
I think the only IDE that comes close at the moment is Spyder (but note that I neither use it myself for everyday work, nor have I used it for teaching so far). It has some great features for beginners like integrated help, a nice history of commands, and an object explorer (quite similar to the MATLAB IDE that some learners might be familiar with). And installation is not an issue, since it comes pre-installed with Anaconda.
IMO, its main downside for teaching is that its GUI layout with 3 sub-frames is not great for projecting it on a screen (in particular with the big font size we need).
I have taught courses (not SWC) using Spyder and, whilst I agree that it's a reasonable solution when there's time, there's a few significant problems that slow it down at the start. In particular, the way it deals with working directories is not intuitive (in general, but especially for novices), which means you have the overhead of teaching shell-like directory stuff, not using the shell. This issue doesn't come up with the notebook, as a notebook is always launched from a directory explicitly.
Based on the courses I've done I'd recommend the notebook for short (<1 day) courses with absolute beginners, ignoring all shell issues, and spyder and a slower shell introduction for longer courses, or courses with people with a little background.
On Wed, Feb 10, 2016 at 2:36 PM, Marcel Stimberg notifications@github.com wrote:
I've experimented with several Python IDEs, and none of them measures up (certainly not to RStudio). What other options do you see?
I think the only IDE that comes close at the moment is Spyder https://pythonhosted.org/spyder (but note that I neither use it myself for everyday work, nor have I used it for teaching so far). It has some great features for beginners like integrated help, a nice history of commands, and an object explorer (quite similar to the MATLAB IDE that some learners might be familiar with). And installation is not an issue, since it comes pre-installed with Anaconda.
IMO, its main downside for teaching is that its GUI layout with 3 sub-frames is not great for projecting it on a screen (in particular with the big font size we need).
— Reply to this email directly or view it on GitHub https://github.com/swcarpentry/python-novice-gapminder/issues/15#issuecomment-182400104 .
In particular, the way it deals with working directories is not intuitive (in general, but especially for novices), which means you have the overhead of teaching shell-like directory stuff, not using the shell. This issue doesn't come up with the notebook, as a notebook is always launched from a directory explicitly.
I get this point in general (in my understanding, this is also one of the main reasons why we use nano in the shell lessons), but is this really so different from the ipython notebook? If I am not mistaken, under Windows most learners launch the notebook via the menu item installed by Anaconda, without explicitly specifying a working directory. Conversely, you could start Spyder from a directory of your choice by starting it via the spyder
command from the terminal, but then this of course would need some minimal shell knowledge (cd, ls, pwd, ...).
The working directory in Spyder is not the directory you launch it from: it stores the working directory between sessions, can be linked to projects, etc. (At least this is the case on Mac). So if you want the student to write multiple scripts in different directories, they'll need to change working directory inside spyder for each script/project.
On Wed, Feb 10, 2016 at 2:58 PM, Marcel Stimberg notifications@github.com wrote:
In particular, the way it deals with working directories is not intuitive (in general, but especially for novices), which means you have the overhead of teaching shell-like directory stuff, not using the shell. This issue doesn't come up with the notebook, as a notebook is always launched from a directory explicitly.
I get this point in general (in my understanding, this is also one of the main reasons why we use nano in the shell lessons), but is this really so different from the ipython notebook? If I am not mistaken, under Windows most learners launch the notebook via the menu item installed by Anaconda, without explicitly specifying a working directory. Conversely, you could start Spyder from a directory of your choice by starting it via the spyder command from the terminal, but then this of course would need some minimal shell knowledge (cd, ls, pwd, ...).
— Reply to this email directly or view it on GitHub https://github.com/swcarpentry/python-novice-gapminder/issues/15#issuecomment-182408860 .
Ah, thanks for clearing this up! Before writing my previous comment, I launched a freshly installed spyder from the terminal and it showed the directory I started it from as the working directory, so I assumed that would be the case all the time. But you are right, starting it from a different directory will no longer change the working directory now, it remembers the working directory from the first start...
Still, I am 100% not convinced that it is easier to have learners with no shell experience navigate to the correct directory in the shell and then launch ipython notebook
compared to launching spyder (in whatever way) and then setting the working directory via a few button clicks in the GUI.
@gvwilson I get your point that python may be taught to people who don't know shell. But often in SC workshops the Python lecture comes after the shell introduction and it might build upon the skills. In this case using ipython (for interactive exploration) + shell (for running scripts) + editor such as nano or atom (for writing scripts) might be a better option.
Would it be reasonable to have two variants of the lesson - one with notebook and one in an editor?
FWIW, I'm generally +1 on using notebooks in pedagogy mode (unless you're explicitly teaching things like modularization and creating packages). I think people underestimate the benefit of having markdown + plots + code all in one place that persists over sessions. I still haven't found a good "pure code" teaching implementation that doesn't feel clunky (e.g., lots of commented explanatory blocks that don't look nice and don't have any formatting). Though I think it's a good idea to keep reminding students that they should take coherent chunks of script/function/etc that's in a notebook and put them into .py
files whenever they can.
On Wed, Feb 10, 2016 at 08:26:15AM -0800, Marcel Stimberg wrote:
Still, I am 100% not convinced that it is easier to have learners with no shell experience navigate to the correct directory in the shell and then launch
ipython notebook
compared to launching spyder (in whatever way) and then setting the working directory via a few button clicks in the GUI.
I think the easiest approach here is to put everything (including data downloads) in the notebook / IDE. Then you avoid the disconnect between “the notebook / IDE's current working directory” and “where you downloaded the data”. You avoid issues like wget vs. cURL (e.g. swcarpentry/sql-novice-survey#117), and may be able to avoid talking about directories entirely.
Folks who want to use these tools in their daily/weekly research will be well served by shell-novice-level familiarity with a POSIX shell. But if you're trying to pack all the overarching SWC ideas into a single day for novice learners, I doubt we have time to hit the POSIX shell and another scripting language (Python / R) while still covering version control.
Dropping Python / R and just doing POSIX shell, editor, and version control is another option (maybe focusing on paper authoring? 1), but not for a lesson like this that intends to cover Python ;).
In my opinion, the biggest advantage of the notebook (may also true for some IDEs) is how much typing it saves. Switching from the editor to a shell, saving files in the editor, fixing typos, running previous code fragments, even copy/pasting, etc... is a huge time sink for novice programmers.
The notebook solves all these problems nicely by having basically no interface: there's no need to save, no need to switch windows, full screen mode, one keystroke to run code, even old code...
So, I think that teaching a version of the lesson with another tool that doesn't take all this into account would be a complete disaster.
I would like to link issue #397 which proposes switching to JupyterLab from Jupyter notebook. Using JupyterLab instead of Jupyter notebook might help those instructors such as @gvwilson who teach Python from a console first and then introduce Jupyter notebooks later. Process of launching the Jupyter lab server is the same as launching the Jupyter notebook server..
$ jupyter lab
...instead of the following.
$ jupyter notebook
JupyterLab UI is similar in many respects to RStudio UI. In particular, JupyterLab includes an IPython console/terminal as part of the UI which would help reduce the cognitive load for learners when switching between console and notebooks whilst also providing some much needed flexibility for instructors. I have opened PR #398 with a first draft of changes to incorporate JupyterLab.
I don't see the hesitation with introducing just enough shell for the use of teaching from the command line... As it is, the installation process instructs the learner to install from the terminal.
I know this is revisiting something that has been discussed in several places before, but I worry that the use of a more abstract environment like the Jupyter Notebook might confuse and add an additional barrier to people wanting to "really" use Python.
I have found in that past that also introducing the shell to be a very minor addition, and feel that by teaching Python via the notebook we would only delay this necessary skill. In particular, only a few commands are needed to use the shell well enough to navigate and run Python scripts, and they are the same commands on both windows command prompts and linux/macos terminals.
On the other hand, by using the notebook, the students are blocked from simple concepts like importing functions etc. defined in other scripts.