Support REPL

[pdawyndt]

Support REPL for interactive Python use.

[winniederidder]

When talking about a REPL, are you thinking of something similar to futurecoder (i.e. run the code, then be able to execute extra statements in the input field using the variabls defined in the code that you ran) or are you envisioning an entirely different execution mode that just contantly prompts without the initial code file?

[pdawyndt]

I have no strong opinion at this moment whether we should provide it completely independent from the batch-execution or mimick the same behaviour as futurecoder and some other IDEs (e.g. PyCharm also provides an open "Execute file/selection in Python Console").

When I'm teaching/programming Python myself, I'm regularly using the REPL to demo something or try something out, so switching between the editor window and a REPL should be as smooth as possible.

[winniederidder]

It's equally easy to demonstrate this in the non-REPL environment by just adding lines to it and then running. Sure, you may need to add print statements or something, but later on in Dodona they will not have such a REPL (so they may be confused why certain things don't work anymore). The essence is, with running code being made so easy, what is the added benefit of a REPL?

[winniederidder]

To add to this, the REPL doesn't provide linting, autocompletion, syntax highlighting, all of which are very helpful features. Demonstrating in Papyros would grant this potential.

[pdawyndt]

What is the added benefit of a REPL?

Almost all IDEs provide the option to run a REPL next to an editor with batch execution, and they do support autocompletion, syntax highlighting, command history, ...

Interactive shell is good for learning: work statement by statement, inspect result, use variables in global scope. Interactive shell is good for quick testing/experimenting with some Python features before applying them in your code. Google may give you some more advantages (and disadvantages) of working in the interactive shell, compared to running scripts in batch mode. Same ideas apply to working with unix shell in interactive and batch mode.

[winniederidder]

Almost all IDEs provide the option to run a REPL next to an editor with batch execution, and they do support autocompletion, syntax highlighting, command history, ...

The main concern with providing a REPL is that the code will not be run in a REPL-fashion in Dodona. Students might presume things should work because of statements they executed while forgetting to include them in their submission. As such, we need tangible benefits that are not presentwhen using the main editor.

work statement by statement,

Simply add a new line below the latest and click run again, with the benefit of having your code saved and ready to be handed in.

inspect result

Explicit is better than implicit, according to the ways of Python. If they want to inspect variables, they can add a call to print. This has the benefit of leading to the same behaviour when submitted in Dodona

use variables in global scope

Defining a variable outside of a function in your script that will be run will make it act in the same way as REPL would, so I don't see how this is a new benefit?

Interactive shell is good for quick testing/experimenting with some Python features before applying them in your code.

With running code in Papyros being so easy (with the extra benefit of automatic installs, thus not requiring you to setup a venv to quickly test things in e.g. numpy), I think quick testing/experimenting is very much supported by Papyros without a REPL. Furthermore, when later on some features from #182 are implemented, experimental code could be separated into a separate file to avoid polluting the main code, while still being easy to use. Finally, commenting out code in your script allows you to retain what you had while running only specific parts.

Google may give you some more advantages (and disadvantages) of working in the interactive shell, compared to running scripts in batch mode. Same ideas apply to working with unix shell in interactive and batch mode.

If my terminal opened with an easy to use editor that could be run instantaneously, I would likely use that instead of the default REPL.

@bmesuere Maybe you also want to add your thoughts?

[pdawyndt]

@winniederidder I think this completely bypasses the complementarity of having an IDE where you can combine writing and running code in interactive and non-interactive mode. The Python community has heavily invested in environments that work as an interactive shell. After the initial REPL, work started in IPython (more REPL features, which has then emerged into IPython Notebook (REPL-like environment in browser), which was later rebranded as Jupyter Notebook as more and more languages took over the concept with their own execution kernels.

First thing you find on the Pyodide website is a REPL that visitors can use to run Python code in the browser. One of the current projects that drives Pyodide development is Pyolite; Jupyter Notebook with Python-kernel that runs in the browser (instead of server-side execution).

Notebooks is still another adventure that we may have to think about in the future, but I definitely think having a REPL embedded in Papyros would be a good asset. Whether this should be implemented in the course of your master thesis is another issue, but at least I would recommend to put it forward as a valuable avenue for future development in your thesis text. Having three out of six secondary schools teachers hinting on providing a REPL in Papyros should underscore this.

[alexmojaki]

REPLs lower the barrier to experimenting and exploring and that has great value. Actually running code to see what will happen is important and useful and making it as convenient as possible makes a difference.

That advantage applies to the student using the REPL themselves, not so much to a teacher demonstrating to the class, but simply showing a REPL in action and thus implicitly encouraging students to use it themselves is still nice. In any case, Papyros seems mainly targeted at the large number of students who can't all easily install Python themselves, not the smaller number of teachers who can usually install whatever tool they want for their use case.

Linting is not really relevant in a REPL. Syntax highlighting is less important than in the editor. Autocompletion is nice, but a REPL is still worth it even without it.

The 'backend' of a REPL is not difficult and python_runner can mostly take care of it, but the frontend is a significant project and leaving this for later certainly seems fair.