Explain printing/returning and REPL better about intro-to-python HOT 26 CLOSED

Is that still an issue with Python 3.4?

from intro-to-python.

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.

from intro-to-python.

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 :-)"

from intro-to-python.

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.

from intro-to-python.

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.

from intro-to-python.

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.

from intro-to-python.

+1
On Sep 14, 2014 8:37 PM, "Audrey Roy" [email protected] 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
#7 (comment)
.

from intro-to-python.

@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 :)

from intro-to-python.

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

from intro-to-python.

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.

from intro-to-python.

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.

from intro-to-python.

@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.

from intro-to-python.

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.

from intro-to-python.

@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!

from intro-to-python.

@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:

from intro-to-python.

+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.

from intro-to-python.

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

from intro-to-python.

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.

from intro-to-python.

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

from intro-to-python.

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.

from intro-to-python.

@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).

from intro-to-python.

@treyhunner good points on both :)

from intro-to-python.

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

On Tue, Sep 16, 2014 at 10:12 AM, Trey Hunner [email protected]
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
#7 (comment)
.

from intro-to-python.

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.

from intro-to-python.

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

from intro-to-python.

Closing this issue since it is addressed 🍪

from intro-to-python.