3 ms·

(author of post) I am a huge fan of this approach and use it extensively in my own code. This natural commandline interaction is completely alien to my student

(author of post) I am a huge fan of this approach and use it extensively in my own code. This natural commandline interaction is completely alien to my students. They are barely holding on with trying to learn Python in the notebook environment, telling them that the solution to their problem is to learn another language has not woked well for me.

yellowapple 8y ago
Gotcha. Given that Jupyter feels pretty alien to me coming from a command-line-heavy background, I can understand the stubbornness :) In that case, I'd probably more readily recommend just adding a *.csv line to .gitignore and letting students add/remove files accordingly (unless the lesson is specifically about how configuration files work, of course, in which case by all means your approach is reasonable).
- chthonicdaemon 8y ago
  Adding the .csv files to .gitignore only avoids the one issue of having checking in data files. How do collaborators ensure they’re working on the same data files? I am aiming to minimise the manual steps involved in running the latest version of the code on the latest version of the input data. With my system you just pull the latest code and run it.
  - yellowapple 8y ago
    You can have that with gitignored local data files, too, though: since git is ignoring the data, a simple "git pull" will indeed ignore what's already in there. Meanwhile, the answer to "How do collaborators ensure they're working on the same data files?" would be "Drag and drop those files into the source repo from whichever means they wanna use to share them.". Yet another way to skin this particular cat might be to write a script as a drag-and-drop target. I don't think Jupyter supports this, so your students would have to venture beyond it a bit, but your Windows-using students for example can drag files onto actual .py files and those dropped files will show up in sys.argv (I think macOS requires the extra step of using py2app, but that might be a good opportunity for a py2app/py2exe lesson). I'd post sample code like in my other comments, but I'm on my phone at the moment.

yellowapple 8y ago

Gotcha. Given that Jupyter feels pretty alien to me coming from a command-line-heavy background, I can understand the stubbornness :) In that case, I'd probably more readily recommend just adding a *.csv line to .gitignore and letting students add/remove files accordingly (unless the lesson is specifically about how configuration files work, of course, in which case by all means your approach is reasonable).

chthonicdaemon 8y ago
Adding the .csv files to .gitignore only avoids the one issue of having checking in data files. How do collaborators ensure they’re working on the same data files? I am aiming to minimise the manual steps involved in running the latest version of the code on the latest version of the input data. With my system you just pull the latest code and run it.
- yellowapple 8y ago
  You can have that with gitignored local data files, too, though: since git is ignoring the data, a simple "git pull" will indeed ignore what's already in there. Meanwhile, the answer to "How do collaborators ensure they're working on the same data files?" would be "Drag and drop those files into the source repo from whichever means they wanna use to share them.". Yet another way to skin this particular cat might be to write a script as a drag-and-drop target. I don't think Jupyter supports this, so your students would have to venture beyond it a bit, but your Windows-using students for example can drag files onto actual .py files and those dropped files will show up in sys.argv (I think macOS requires the extra step of using py2app, but that might be a good opportunity for a py2app/py2exe lesson). I'd post sample code like in my other comments, but I'm on my phone at the moment.