Explain printing/returning and REPL better

[treyhunner]

I read Some Suggestions for Teaching Python and one of the suggestions regarded teaching the distinction between the return statement and the print function. I think we should make this clear if possible.

[macro1]

Is that still an issue with Python 3.4?

[treyhunner]

I think so. The Python REPL always prints after executing, so a() can seem to do the same thing with a print instead of a return.

[willingc]

Perhaps a way to address this (if that is desired) would be to use Nick's two examples with a tiny change.

def print_my_parameter(x):
    print(x)

def return_my_parameter_unchanged(x):
    return x

a = 6
b = "I am a string!"
c = "I am not a number"
d = -7.5
e = "Wow. Strings and numbers are different. Print and return do different things. Isn't it weird that sometimes they display the same thing? Welcome to programming :-)"

[treyhunner]

What about showing how you could use a function call as part of a larger expression?

def add(x, y):
    print(x + y)

print("x + y is", add(x, y))

# vs.

def add(x, y):
    return x + y

print("x + y is", add(x, y))

The first one should not act in the way the student would expect.

[treyhunner]

I'm tempted to suggest discussing read-execute-print, the difference between the REPL and a .py file, or code reusability to help clarify, but I don't want to distract too much. We could just address this if the misunderstanding occurs and (if needed) make it part of our curriculum for the next workshop.

[audreyfeldroy]

This is an inherent problem with using the REPL to teach functions. To address this issue, I'm thinking of converting part 3 from the REPL to .py files entirely.

[macro1]

+1 On Sep 14, 2014 8:37 PM, "Audrey Roy" notifications@github.com wrote:

This is an inherent problem with using the REPL to teach functions. To address this issue, I'm thinking of converting part 3 from the REPL to .py files entirely.

— Reply to this email directly or view it on GitHub https://github.com/pythonsd/intro-to-python/issues/7#issuecomment-55550217 .

[audreyfeldroy]

@macro1 thanks for the feedback. Okay, I'll go ahead and work on that conversion now. Everyone, please don't touch Part 3 for the rest of tonight until I get my changes in :)

[treyhunner]

@audreyr :+1: I think that's a good idea also. Introducing students to .py files seems great.

[audreyfeldroy]

Still working on this issue as part of Part 3, with @willingc's help. (Thank you @willingc, you're a lifesaver!)

After thinking it over more, breaking down the examples with Carol, and reading What I've learned from teaching, I'm experimenting tonight with creating a set of slides that presents the examples in context, complete with the exercises for students to work through.

If the slides turn out good, there may be no need for typing @alaindomissy, but I'm still figuring it out. I'll keep you all posted.

[audreyfeldroy]

I'm really liking the slides + .py files approach as I work through it! I think it shows the printing vs. REPL distinction well.

Here are some work-in-progress screen captures to give you all a feel for what my slides will be like.

[treyhunner]

@audreyr I really like those slides. Also thanks for the link to Julia's blog post. I hadn't seen it yet.

I like the idea of slides for visual demonstrations and to allow students to see the whole code block instead of watching someone type.

One thing I do like about live coding is the ability to answer student questions by typing at the Python prompt. This didn't happen frequently during the last conference but the few times it did the live prompt seemed useful. Since during this workshop every student will have a Python prompt open, I wonder whether any added value of live coding is lost. Maybe I should open a separate issue to discuss this.

[audreyfeldroy]

No need to convert everything to slides, by the way! The slides are specifically important for Part 3 because of the nature of it being file-based.

I think keeping the live coding as-is for Parts 1, 2, 4 is still good, unless anyone feels inspired to experiment with slides.

[willingc]

@audreyr Julia and her post are great :)

Multiple pathways of learning are important and good to be sensitive and respectful of them. What works best for me? It depends. Sometimes live coding, sometimes a visual demo of slides for longer code blocks, etc. Ironically, I find that I learn coding best when I can draw with colored markers on paper (yes, I know that is popular way :p). I think it helps me visualize and pull together concepts.

Vive la difference!

[willingc]

@audreyr One small suggestion on the slides (unless they are all done). Perhaps a simpler command prompt would be better visually, just a $ or a visual demarcation between prompt and entered text:

[treyhunner]

+1 all of the above. I'll bring up slides again after the workshop once we've seen how students reacted to each section.

As for the prompt, I agree that seeing a $ or > (as it is on Windows I believe) might be helpful. I definitely like the dark-on-light command prompt though. That seems to show up more clearly on the projector.

[audreyfeldroy]

Do you all know of any tools to make fake command prompt screenshots?

[audreyfeldroy]

Agreed, I'll change my prompt to $ if I have time.

Also, how does colorized command prompt output look on the projector, vs. white text on dark background? Just wondering how much effort I should put into the colorization part.

[willingc]

Possibly this. http://doitlive.readthedocs.org/en/latest/

[willingc]

I liked the light background with dark text for the console page. Color not very important here. Just a demarcation $ or just $ after your normal prompt.

Personally, I liked the dark background/colored text when you did the analysis of the source code. It appealed to me visually but more importantly gave me a clear indicator (light - I'm working at the command prompt and dark - I'm understanding the source code) as a student.

[treyhunner]

@audreyr that would be a really useful tool to have for making slides. The only thing I can think of is making colorized command prompts with tools like reStructuredText/Sphinx/Heiroglyph. Like:

.. code-block:: bash

    $ something

.. code-block:: pycon

    >>> print("hello")

@willingc I think that doitlive may be different. I think it's supposed to emulate live presentations with ridiculously fast typing (like some of Gary Bernhardt's live demos).

[willingc]

@treyhunner good points on both :)

[alaindomissy]

@willingc https://github.com/willingc @treyhunner https://github.com/treyhunner thats funny !

On Tue, Sep 16, 2014 at 10:12 AM, Trey Hunner notifications@github.com wrote:

@audreyr https://github.com/audreyr that would be a really useful tool to have for making slides. The only thing I can think of is making colorized command prompts with tools like reStructuredText/Sphinx/Heiroglyph. Like:

.. code-block:: bash

$ something

.. code-block:: pycon

>>> print("hello")

@willingc https://github.com/willingc I think that doitlive may be different. I think it's supposed to emulate live presentations with ridiculously fast typing (like some of Gary Bernhardt's live demos).

— Reply to this email directly or view it on GitHub https://github.com/pythonsd/intro-to-python/issues/7#issuecomment-55777236 .

[audreyfeldroy]

Okay, thanks. We have a projector at home, so I'll try it out and make sure the colors are readable.

I will probably stick to non-colored terminal text then, but I'll play with colorizing if I have time.

For background colors, I will also make sure that the command prompt bg is different from the text editor bg.

[audreyfeldroy]

I've got this 100% covered. Everyone, please trust me to finish it and give me room to breathe :)

[willingc]

Closing this issue since it is addressed :cookie: