Python motivation

[snacktavish]

This is a rough version of motivational slides for python - based on @sritchie73's R motivational slides. Idea is that they would be presented at the beginning of a python lecture. Thoughts?

[katyhuff]

Hi there, I'm happy to review this if you like. Any objections?

[wking]

On Wed, Jul 23, 2014 at 01:52:31PM -0700, Emily Jane McTavish wrote:

This is a rough version of motivational slides for python

This looks reasonable to me. Personally, the pitch for Python breaks down into a generic:

“Write software, because the more work your computer is doing for you, the easier it is to reproduce your results. Also, you're going to be writing down your methods anyway, so you might as well write them down in a way a computer can understand ;).”

For folks that buy the generic idea (or a more elaborate version, showing the awesomeness of an automated workflow and/or hazards of a manual workflow), there's a tool-level pitch:

“Use Python, because it's a popular general-purpose, free-as-in-freedom, scripting language that's focused on enabling explicit, readable code. It also has a huge collection of third-party packages that probably already do most of what you need.”

Then I'd go on and unpack each of those terms, and explain why you want something that's popular, or general-purpose, or … (or explain whichever the audience is interested in).

I think you hit on most of those points, but if we split this into separate “Why program” and “Why Python” decks, we can collaborate with the R (etc.) folks on “Why program” ;). Once you've established a set of desirable traits, the “and not…” page (and maybe the whole “Why Python?” deck?) is just a table with traits, languages, and check marks.

In fact, maybe you don't even need a “Why $LANGUAGE?” deck, and can just verbally hit on the way $LANGUAGE delivers for each useful trait. Maybe we want a generic “Why program, and what to look for in a language” deck, and then Python/R/… notes for the speaker to emphasize? Or Python/R/… versions of the generic deck that drop in Matplotlib/IPython/… images (or their R/… equivalents) at the appropriate points?

Or maybe the benefit of collaboration is not worth the mental overhead, and we do just want to go with something like this?

[gvwilson]

Please go ahead.

[gvwilson]

@snacktavish Will you have time in the next week to revise this, or should we hand it off to someone else?

[snacktavish]

Yes! I'll get on it this week.

On 09/08/2014 08:36 AM, Greg Wilson wrote:

@snacktavish https://github.com/snacktavish Will you have time in the next week to revise this, or should we hand it off to someone else?

— Reply to this email directly or view it on GitHub https://github.com/swcarpentry/bc/pull/623#issuecomment-54817778.

Emily Jane McTavish Postdoctoral researcher Department of Ecology and Evolutionary Biology University of Kansas 6031 Haworth Hall 1200 Sunnyside Avenue Lawrence, Kansas 66045 lab phone: 785.864.5789

[snacktavish]

OK! I incorporated the very helpful comments from @katyhuff and @r-gaia-cs and updated it. I did not have a chance to really address @wking 's more in depth comments - I agree a different approach may be valuable, but I also often am asked: Should I learn, R, Python, Perl or...X. So I agree that this deck conflates why program with why program in Python. But I feel ok about that!

[wking]

On Thu, Sep 11, 2014 at 11:12:01AM -0700, Emily Jane McTavish wrote:

So I agree that this deck conflates why program with why program in Python. But I feel ok about that!

I'm ok with it too, since we don't have to have something that lets us collaborate with the R folks on putting down JavaScript ;). We can always revisit this later if we need help keeping this fresh.

Also:

And PyPI is now up to 48622 packages (not 46537), so I'd just say “more than 48k packages” to make this a bit more future-proof.

Do the two master-merges (8d6f96ec and 8f7a4544) bring in anything important? I don't expect you had any conflicts to resolve, in which case, I'd just skip the merges. If you did have conflicts, I'd prefer rebasing to merging ;). Still, this is a minor thing.

[snacktavish]

@wking Good point, I'll update those numbers. And I don't really know on the master merges. I was getting permission problems on pulling, and so fetched and merged instead, but I'm not really sure why! There weren't any conflicts or anything.

[wking]

On Thu, Sep 11, 2014 at 11:30:13AM -0700, Emily Jane McTavish wrote:

And I don't really know on the master merges. I was getting permission problems on pulling, and so fetched and merged instead, but I'm not really sure why! There weren't any conflicts or anything.

It's usually best not to merge from master into a feature branch. See the “useless merges” comment in [1](http://git-scm.com/docs/git-rerere.html#_discussion). For more detail, see Linus' somewhat caustic rant when David Miller did this sort of thing in a Kernel branch [2,3,4]. As Linus points out in [4](https://lkml.org/lkml/2011/3/10/572), it doesn't really matter if the master-merge isn't both recent and your last commit. In general, if you get in the habit of recording the “why” in your commit messages, you'll catch yourself while you're making these sort of reflex merges in the future, and can abort them earlier ;).

If you rebase the branch on master, it will drop the merges. I'm happy to talk you through the rebase on #sciencelab, but I'm also fine skipping that. I'm mostly bringing it up to help avoid future occurrences ;).

[snacktavish]

@wking Interesting! Pedantry accepted. This is my first PR to large project, and am interested to know what is standard practice. I'll investigate the links.

[gvwilson]

@abostroem @tbekolay Please merge if you think this is close enough - we'd like to clear the decks before #759.

[tbekolay]

LGTM! Great start that can be perfected later on. I merged, and added a commit to fix a few minor things (an errant ">" was showing up on all slides, and some slides had text flow off the screen). See 4e0a1ab2731e for full details.