Features and goals to support beginning students and desktop portability

[cyust]

Hello,

Thanks again for working on this library! We are considering using turtle graphics as a supplement to traditional text-based I/O instruction. We don't need to base an entire course around turtle graphics in a web browser, but we're thinking that mixing in some graphical turtle examples - alongside traditional console I/O - for things like sequencing, decision-making, and loops will be fun for the students.

After experimenting with turtle-pyscript for a few days, I wanted to share some overall goals we'd have as potential users who are trying to teach beginning students introductory Python. The big advantage to using an online, web-based solution like this is that you don't have to install Python on a local device, which is often not possible in a school setting (especially with Chromebooks). However, we want to be careful to avoid teaching - wherever possible - syntax, patterns, or concepts just to make the online coding environment work and that would not be relevant or portable to a standalone Python script running on a desktop environment. We want our students to be able to code outside of our online environment after the course ends.

While I am sure it's not realistic, ideally, any standard Python turtle code that would run on a desktop and produce a specific effect would work exactly the same way in an online emulator or vice-versa, subject naturally to certain complex features not being supported online (either by turtle-pyscript or pyscript itself). Put another way, having a reduced feature set online is acceptable, while having to code things differently online vs. desktop is undesirable. Here are some things we encountered:

• Having to "import turtleps" instead of "import turtle" (though "import turtleps as turtle" is a reasonable workaround)

• Support for multiple Python source files (e.g. one main file and supporting classes or functions in other files) in the online environment - not sure if this is possible?

• Interactive code (e.g. detecting and processing mouse and keyboard clicks) seems to be very different online vs. desktop. Possibly this is still a work-in progress, but things like turtle.onclick() are not yet supported, so based on the rocket example, we have to import the document library and engage with HTML/JavaScript-related concepts like this...

def key_down(event):
keys_pressed.add(event.key)

def key_up(event):
if event.key in keys_pressed:
keys_pressed.remove(event.key)

main logic

keys_pressed = set()

document.onkeydown = key_down
document.onkeyup = key_up

while True:
if "ArrowUp" in keys_pressed:
turtle.forward(4)
if "ArrowLeft" in keys_pressed:
turtle.left(5)

...whereas in desktop turtle we'd do this instead:

def arrow_up():
turtle.forward(4)

def arrow_left():
turtle.left(5)

def arrow_right():
turtle.right(5)

screen.onkeypress(arrow_up,"Up")
screen.onkeypress(arrow_left,"Left")
screen.onkeypress(arrow_right,"Right")
screen.listen()
screen.mainloop()

• As beginners, our students will have no concept of threading and concurrency, just trying to learn basic sequencing, decision making, and loops. We would avoid all types of "async" and "await" decorations completely if possible, as they wouldn't be understood and wouldn't port into a desktop python script. I respect your architectural direction is to lean heavily on these concepts as they are appropriate for the web browser, but I wouldn't teach them to beginning students learning Python on a desktop.

• Timing differences - and I know this will run into hard browser limitations - but things can be drawn at certain speeds in desktop turtle, while the same code run online produces instant results.

• Lastly, I'll mention that we would want the ability to redirect all console I/O to a designated panel or <textarea> so the student could see text output (including syntax errors, exceptions, and print() output). Currently, those outputs go to console.log(), though perhaps there is a way to redirect that I didn't find.

Thanks for your consideration!

[DavidLeoni]

Hi,

thanks for sharing, I guess it's time for a 'State of the Project' moment :-)

From the sound of it your use case looks like the 'Single Sprite mode' I described in use-cases.md
which I had initially in mind, that is porting turtle to the browser almost 1:1 and then add a little additional fancy stuff in a separate game engine part (currently it's all in turtleps.py).

Currently this project strength lies in providing a near-serverless way to develop games with just Chrome and very little dependencies. Alas, it also suffers from the limits of both turtle and pyscript:

Turtle problems

In addition to what I stated in api-design.md turtle problems section, I would add that original turtle lacks important features for doing any serious game:

1. bitmap images are not resizable/tiltable/offsettable (only polygons are)
2. only supports .gif format
3. there are no proper layers (last turtle to draw draws on top of others)

In the web version I solved them, but the moment pupils would want to port to desktop a minimally non-trivial game with images, they would immediately encounter serious problems. And a game without images... is just sad.

Pyscript / web problems

Concurrency: My initial idea was to introduce gradually students to concurrency in what I've called Multiple Sprites mode in use-cases.md. I thought about it for months and I still haven't found a satisfying solution. There are many ways to address concurrency, but each has its own pro/cons. If you look around educational projects using python, some people use supermagic @ decorators, others use methods that both work with and without async, others svg animations. If this is what matters the most to you, you might want to look into this other port which adopts the svg animation approach. I didn't take it as starting point because it has GPLv3 licence which is viral, so in general not very suited for a library (at least that's my opinion). Also, it doesn't support pop ups nor seem to support click event which would seem a very easy thing to implement but it's definitely not due to Chrome bugs.

interactivity: in web world there are (too) many ways to attach events to elements. Then we would have the turtle way. To limit confusion so far I decided to provide via examples only the most basic 'close to the metal' webby one. This doesn't prevent in the future to add an optional turtle way on top of it.

print output: so far I favored pyscript defaults, which are just output to console because I expect students to debug a lot and have to open the devtools anyway (or may call text popups instead), but I'm pretty sure pyscript docs mention somewhere a simple way to redirect .

multiple files import: if you have actual files, this is easy to solve, just list them in pyscript.json "files" section as I did for turtleps.py. If you have transient scripts from forms, then maybe I guess that would require some hacking, maybe you could wrap them in some pseudo module created on the fly when injecting into the iframe.

What about now?

Currently my priority is fixing performance issues. In the future, to solve the tension stated above between web and turtle compatibility, I think it would help separating code so to have:

1. a game engine, let's call it cdtn_ge.py for lack of a better name, where things are done 'the proper web way', so embrace async, use native click events, no singletons, and have a convenient (but still close to the metal) Sprite API
2. a turtleps.py (or turtle.py if you will) that imports the game engine adding a turtle compatibility layer, which would ideally support the almost 1:1 use case you described.

As you see I'm still exploring stuff, so if you have any idea / suggestions they're welcome.

[cyust]

Thank you for the detailed reply! You are right, our general use case most closely matches using a single sprite or turtle. Our course does not touch on video game topics, so we're focused on the best way to illustrate straightforward sequencing, loops, and decision-making. We are aware of other packages (e.g. https://brython.info/gallery/turtle.html) that basically let you do a straight "replay" of turtle commands to animate a sequence. However, they do not have any user interactivity, which would be a "nice to have" for us, primarily to demonstrate some basic event-driven concepts towards the end of our course.

I like the idea of splitting the library into a game-centric piece and a turtle-centric piece. We were originally drawn to the project as it seemed to be focused on simulating "Turtle with Pyscript", but if the real attention is on game development with Python in a web emulator...perhaps Turtle compatibility isn't important or is a hindrance.

We are in the early stages of course development ourselves and months away from needing to make a decision on adopting a specific JavaScript library, so we'll check in here periodically to see how you are progressing :).