Dear All,
On Fri, May 06, 2016 at 10:20:41AM -0400, Ivan Gonzalez wrote:
> Hi,
>
> I do a similar thing. I usually start by running a simple statement
> (print("Hello") or something alike) from the Python interpreter, then from
> IPython, and then from the Jupyter notebook. (This was more important
> before the renaming of IPython notebook to Jupyter).
I've used the same approach in the past (not in official SWC workshops
to be pedantic, but in teching computing / Linux to scientists in general).
I'd type some Python line-by-line into the plain vanilla interpreter,
pointing out that "now we have a different prompt, the Python prompt,
so we have to type Python code to be understood". Then (well before starting
with program flow control, because getting indentation right when typing
interactively is not a skill I really possess) I'd write the line(s)
known by then into a script, and go through the cycle of edit -- save
-- run -- check results a number of times quite explicitly and without
introducing new stuff that could be distracting at this point, to get
everyone familiar and comfortable with that cycle.
>From my own experience, that cycle is one of those things that may appear
trivial to the initiated (most instructors), but can make a real difference
in terms of enabling learners to go on learning after the workshop.
One observation I have about using the numpy based intro is that this
can be confusing to participants. I got the question "what do these plots
mean?" after we had been through a couple of them.
Generally, not all particpants are not familiar with the concept of plotting
a matrix of numerical values using some arbitrary colour scheme. Without
some practice / familiarity / mental model of that, they may end up with
dual cognitive demands of having to match the colour-coded plot to the
time-courses (with the peak in the middle), and trying to figure out the
indexing and slicing (some of which is rather fancy and not standard
Python).
For these folks, introducing Python via a bunch of simple statements may
be more beneficial.
Best regards, Jan
> Every time I open and close the corresponding tool, noting the differences
> when pressing "Enter". This allows me to stress the difference between
> Python, the language, and python, the program, and the rest of the tools.
> This is useful if later in the class if I have to open/restart the
> notebook. It good to note here what's Anaconda too.
>
> Then I introduce arithmetic operators with a simple statement (say 1+1) and
> then variable/names to save the result of the operation (say two = 1 + 1)
> and briefly talk about the memory, objects and names.
>
> This is very quick ~10 mins, but allows you to set some vocabulary (object,
> name, statement, operator, ...) and some idea of what's happening
> memory-wise which you may need later.
>
> Then I follow the lesson importing numpy. I take advantage of the previous
> definitions and usually say here that numpy is just another name which
> refers to a bunch of code that is now loaded in memory and that was
> installed as part of Anaconda.
>
> Best,
>
> Ivan
>
> On Thu, May 5, 2016 at 5:50 PM, Byron Smith <[email protected]> wrote:
>
> > After my first time teaching python-novice, I decided to always skip the
> > first section. Instead I work it in later while showing the use of
> > packages.
> >
> > Although I understand why the Python lesson is structured the way it is,
> > and I like the idea of an application-first approach, this particular
> > implementation has been difficult for learners in my experience. I look
> > forward to seeing the new lesson as it takes shape.
> >
> > Instead I have had great success with the more traditional, "bottom-up"
> > approach. Luckily, that's what you end up with when you remove section one
> > from the current lesson.
> >
> > While my experience contradicts the general SWC belief that material needs
> > to be motivated early, I've found learners to already believe that they
> > should learn Python, making a focus on motivation less important. This is
> > probably not the case for the shell and git lessons.
> >
> > -Byron
> >
> > On Thu, May 5, 2016 at 4:35 PM, Maxime Boissonneault <
> > [email protected]> wrote:
> >
> >> Hi Alexandre,
> >> I find that starting with Numpy is great, because it allows to do
> >> interesting things without the need for introducing weird and boring
> >> concepts like loops, variables or conditionals.
> >> Students immediately can relate to things they know like seeing a
> >> picture, or seeing a table of numbers.
> >>
> >> Starting with abstract concepts like variable naming, loops,
> >> conditionals, etc, is bound to bore students, which is never a good thing
> >> at the very beginning of a class.
> >>
> >> Cheers, and have a good first time!
> >>
> >>
> >>
> >> --
> >> ---------------------------------
> >> Maxime Boissonneault
> >> Analyste de calcul - Calcul Qu??bec, Universit?? Laval
> >> Pr??sident - Comit?? de coordination du soutien ?? la recherche de Calcul
> >> Qu??bec
> >> Team lead - Research Support National Team, Compute Canada
> >> Instructeur Software Carpentry
> >> Ph. D. en physique
> >>
> >>
> >> On 2016-05-05 15:16, Alexandre Manhaes Savio wrote:
> >>
> >> Hi,
> >>
> >> I am preparing for the first time the python-novice-inflammation lesson.
> >> I am also going to add in the beginning instructions on the most popular
> >> initial options on how to actually run the python code.
> >>
> >> I am struck on how the novice lesson directly starts with Numpy without
> >> explaining too much variable naming and assignment, for instance. In my
> >> case I will begin with students with very little programming experience.
> >>
> >> I am also aware that Greg is preparing another lesson for python but there
> >> is some work there to be usable.
> >>
> >> Could you please write me your opinion and experience about how you
> >> prepare the beginning of the python novice lesson?
> >>
> >> Thank you very much!
> >>
> >> Best,
> >> Alex
> >>
> >> Alexandre Manh??es Savio
> >> PhD, Medical Imaging, Machine Learning
> >> Klinikum rechts der Isar, TUM, M??nchenalexsavio.github.io | email:
> >> [email protected]
> >>
> >>
> >>
> >> _______________________________________________
> >> Discuss mailing
> >> [email protected]http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
> >>
> >>
> >>
> >> _______________________________________________
> >> Discuss mailing list
> >> [email protected]
> >>
> >> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
> >>
> >
> >
> > _______________________________________________
> > Discuss mailing list
> > [email protected]
> >
> > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
> >
> _______________________________________________
> Discuss mailing list
> [email protected]
> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
--
+- Jan T. Kim -------------------------------------------------------+
| email: [email protected] |
| WWW: http://www.jtkim.dreamhosters.com/ |
*-----=< hierarchical systems are for files, not for humans >=-----*
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
