Avant-IDLE: an experiment

[Edit: this post has an embedded video, which is not visible for PlanetPython readers.]



This is a follow-up from a previous post where I showed just a screenshot made after one hacking session.  A week later, much has changed.

As noted at the end of the video, the code is not (yet) available in a public repository.  Among other things, I need to figure out what license I can use and if I can reuse all of the content from Python's version, or if I need to remove certain assets, etc.

Avant-IDLE makes use of two projects that I started recently and mentioned before on this blog:

Friendly-traceback (code, documentation) and AvantPy (code, documentation). AvantPy itself depends on Friendly-traceback.

Both Friendly-traceback and AvantPy welcome contributions.  Publishing this video about AvantPy is a way to bring more attention to these other two projects.

Going forward with Avant-IDLE

As for Avant-IDLE, if I can go forward with it:

• I would like to translate its menus.
• I would like to add syntax coloring for each individual dialect: this would likely mean some significant change from the way that syntax coloring is done in IDLE.
• I would like to have friendly tracebacks make use of color, like iPython does.
• I would like to add line numbers to the file editor.
• etc.

I might have to remove the debugger, as it makes little sense to have someone entering code in their native language and suddenly have to deal with standard Python since that is the code that is truly executed.  I think that, by the time someone is ready to use a debugger, they are definitely ready to use Python itself.

In an ideal world, save for the "dialect converter" demonstrated in the video, I would like for the rest of Avant-IDLE to be in a single window, with files in tabs and the interpreter below, like Al Sweigart described:

However, that last idea might be something simply too ambitious. After all, Al Sweigart, who is far more competent and productive than I am, never managed to get that project off the ground. The more the code base from Avant-IDLE diverges from that of IDLE itself, the more difficult it will become to incorporate code changes made by Python's core developers to improve IDLE.

Making the code public

Even if I figure out all I need to do to make Avant-IDLE public, I am somewhat hesitant in doing so.

There is no doubt in my mind that I can continue working and improving both Friendly-traceback and AvantPy.  I truly believe that Friendly-traceback could be very helpful for Python beginners.  It could be integrated in other beginner-friendly editors, like Mu or Thonny - two fantastic projects.

I think that AvantPy could be useful for beginners as well ... but I do admit that it is a bit quirky.

When it comes to Avant-IDLE itself, as the saying goes, I don't want to bite more than I can chew, and find out that I created something which I cannot maintain. I do realize my limitations: I am just a hobbyist with no formal training in programming and who likes to do quirky experiments in his spare time. Publishing code on Github and/or making it available at Pypi automatically raises people's expectations, and demands on one's time.

Still, if this video can inspire you to create something useful for beginners, it will have been worthwhile.  Even more so if it inspires you to contribute to either Friendly-traceback or AvantPy, ;-)

Comments?

If you have any constructive criticism, or suggestions to offer, please feel free to do so, either on this blog, or by email.

Test - please ignore

Simple test to embed a gist.


That's all.

Idle hacking - part 1

1. File test_py.pyfr.  The pyfr extension indicates that this is written in the "French Python" dialect. Since this is the main file we'll run, it will also automatically set the language to French. This is all done by AvantPy.
2. "afficher" is the French version of "print"
3. "import" is the normal Python keyword; we can mix and match keywords from a given dialect with the normal Python ones.  Here, we are importing a module whose base name is "upper".
4. The constant "a" is defined.
5. File "upper.pyupper"; the only file whose base name is "upper" - thus, the one that will be imported. The "pyupper" extension indicates that the dialect is an "upper case" version of Python - designed for testing.
6. The code that will be run when the file is imported.
7. Output from both files.
8. "a" is defined.
9. We made a syntax mistake. However, Friendly-traceback is there to help us understand what went wrong ... picking up the default language to use (French) from that first file that was run.

All this was run with a crudely hacked version of Idle. I'm still confused with the communications done with the RPCServer and the TPCServer, having never looked at similar code before.  So, I haven't been able to make it do all that I wanted in this first hacking session. Hopefully, there will be more to come ...

Friendlier tracebacks

When beginners run programs that generate Python tracebacks, they are almost always confused by what the information shown and have no clue as to what this all means. More experienced programmers can sometimes extract enough information directly from tracebacks to figure out what what wrong, but they will often have to resort to inserting a few print calls and running their program again to truly figure out what went wrong and how to fix it. (A minority of programmers might eschew using print calls and use a debugger instead.)

In order to make tracebacks more useful for them, some advanced programmers have designed tools to add more information so that simply looking at the enhanced traceback might be sufficient to diagnose properly the problem.  These tools include better_exchook, infi.traceback, rich-traceback, stackprinter, as well as the beautiful better-exceptions, and many others including Python's own cgitb module.  While there is no doubt that the additional information provided by these tools is useful for advanced programmers, it would likely only add to their confusion if it were used by beginners.

Friendly-traceback, a project I have been working on, and mentioned briefly in an addendum of my last post, aims at improving the situation for beginners.

A quick example

Have a look at the following Python traceback that might be generated by code written by a beginner.

Compare this with the following when using Friendly-traceback's own REPL

The only thing that is shown in exactly the same way is the line showing the exception name an a message. Everything else can be made available in other languages as shown below with a French translation.

Currently, Friendly-traceback can offer a more helpful message than a normal Python traceback in approximately 50 different cases, most of which are cases of either TypeError or SyntaxError. My goal is to eventually include explanations for all standard Python exceptions, and include as many sub-cases as possible.

As shown above, it is possible to translate the information in any language. Currently, only English and French are included; inclusion of other languages will require the help of volunteers.

If you write programs with your own custom exceptions, it is possible to write them so that they could be interpreted correctly by Friendly-traceback.  I have done so in another project, AvantPy, which I mentioned previously here. AvantPy includes 10 custom exceptions.

Both AvantPy and Friendly-traceback are available from Pypi. Contributors are most definitely welcome.

AvantPy needs you

Update: Since this blog post was published, and before Pycoder's weekly mentioned it bringing in quite a few visitors, I had decided to carve out the friendlier tracebacks into a separate project. If you are interested in this idea, you can have a look at the design document and feel free to comment.  Work on AvantPy itself has been paused until friendly-traceback's API is completely implemented.  The API itself is easy to do - the tedious work is adding in an explanation for every possible Python exception, and translating each of them ...

Imagine that you are either learning Python or helping someone that is learning Python. It is almost a certainty that you will see some Python tracebacks, often much more complicated to decipher than

Imagine if you could see something like the following instead:

Or, if you speak French:

Friendlier tracebacks, translated into various languages, is only one of many things that AvantPy can do to help beginners learn programming.

AvantPy is very much in its infancy. You can think of it as a proof-of-concept that can be built upon.

PSF's request for proposal

Yesterday, on the PSF's blog, some information about a request for proposal has been posted.
I have jotted down some thoughts about AvantPy in this context. If you wish to add your own thoughts on this, you can do so here. I do not wish to get any direct funding from the PSF for this project. However, some potential collaborators might need some financial support depending on their goals.

What is AvantPy

Here are some useful links if you want to find out more about AvantPy.

• AvantPy documentation; this should probably be your starting point
• Code repository
• AvantPy on pypi.org (not currently tested as I work from my local version.)

Contributors to the AvantPy project are very much welcome.

User feedback is essential for improvements

A while ago, in Reeborg's World, I implemented a way to require Reeborg to follow a specific path in order to complete a task. For a world creator, this meant to include a path as a list of successive grid location, something like

path = [[1,1], [2, 1], [2,2], ...]

With the appropriate information given, the task shown to the user includes a visual view of the path to follow.  This is what it looked like:

This works well. However, if Reeborg has to retrace some steps, to accomplish the task, the two arrow heads visually combine and appear to form an X which could be interpreted to mean that a given path segment should not be included.

(In addition to the arrow heads combining to look like an X, the dashes do not overlap and instead combine to form a solid line.) Most users of Reeborg's World are students learning in a formal setting. I surmise that those teachers quickly figured out what the correct information was and never reported it.  As I created this visual information, I knew its meaning and was simply blind to the other possibility.

A while ago, a user learning on their own asked me why their program was not working. After a few email exchanges, I finally understood the source of the confusion. I took note of it. I had a quick stab at finding a better way but it didn't work.

A couple of days ago, a second user learning on their own contacted me with the same problem. Clearly, something had to be done ...

This is what it now looks like

In addition to clearing the confusion (or, I hope it does), I actually think it looks much nicer. This improvement would not have been possible if I didn't get some user feedback. This is why I am always thankful when someone contact me to suggest some improvements -- even though I may not always be in a position to implement the required changes quickly.

Pythonic switch statement

Playing with experimental and an old recipe created by Brian Beck.

The content of a test file:

from __experimental__ import switch_statement

def example(n):
    result = ''
    switch n:
        case 2:
            result += '2 is even and '
        case 3, 5, 7:
            result += f'{n} is prime'
            break
        case 0: pass
        case 1:
            pass
        case 4, 6, 8, 9:
            result = f'{n} is not prime'
            break
        default:
            result = f'{n} is not a single digit integer'
    return result

for i in range(11):
    print(example(i))

Trying it out

$ python -m experimental test_switch
0 is not prime
1 is not prime
2 is even and 2 is prime
3 is prime
4 is not prime
5 is prime
6 is not prime
7 is prime
8 is not prime
9 is not prime
10 is not a single digit integer

Just having fun ... Please, do not even think of using this for serious work.