Parsons Exercises for Python using Snap!

As a CS teacher I'm trying to implement Parsons exercises for Python, using Snap! blocks and Snap! Codification capabilities.

This way I hope to both strengthen and assess students' understanding and mastery of the basic Python language syntax and idioms.

My shared Snap! project is linked here, and an image is attached.

In the attached image I show custom Snap! blocks representing Python syntax (#1 and #2). And a mapping of these blocks to Python Syntax (#6 and #7).

In order to create the appropriate Python indentation (which is part of the language syntax), I have one "print" statement (#6) where the indentation is done with "_____" (underscores), and another "print()" statement (#7) where the indentation is " " (spaces).

The Codification mapping for spaces (#7) works -- see the Python output (#4), but the pring with the underscore indentation (#6) does not work (see #4, second print has "4" in front of it).

Is there a way to count the number of underscores (like I tried to do in #8), so that different amounts of indentation (per the Python syntax requirements) can be mapped by Snap! into the correct output code?

Thank you!
Attached screenshot:

In MAP ALL COMMANDS, in the translation of number 6 you have INDENT <#1>. INDENT takes a string as input and reports its length. So, if you give it a string of either four spaces or four of anything else, INDENT reports 4 and that's what's printed!

You might want to explore to using a text to costume block for showing your code (to visulise the indenting properly)

Parsons tests 2 script pic

image

Thanks, Brian.
The problem as I see it is that INDENT <#1> is incorrectly reporting the length of the actual characters of the string "<#1>" which is always 4 characters (see #E).
In the attached, #B has only 1 "_" but statement #D is indented 8 spaces, because len in #G is set to 4 (instead of 1).

Can't embed a screenshot so will post separately.

Thanks, Brian.
The problem as I see it is that INDENT <#1> is incorrectly reporting the length of the actual characters of the string "<#1>" which is always 4 characters (see #E).
In the attached, #B has only 1 "_" but statement #D is indented 8 spaces, because len in #G is set to 4 (instead of 1).

Oh, right, sorry, that flew right past me.

That last input to MAP TO is evaluated just like any old input, i.e., before MAP TO is called. If you look at the examples in Jens's Codification project, you won't find any Snap! blocks in that input slot; it contains target-language code, not Snap! code. This is true even of the JOIN in your translation of IF: It's evaluated before MAP TO, producing the (constant) string <#1>if <#2> == <#3>: which is then handled by MAPS TO as if you'd just typed that in instead of calling JOIN.

So, yeah, you're right, LENGTH OF TEXT is giving you the length of the text <#1> which is 4.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.