Renaming identifiers & debugging

Luca lucat at despammed.com
Fri Feb 26 16:30:58 EST 2010


Roald de Vries wrote:
> I would suggest to do choose the same strategy as 'from __future__ 
> import ...' takes, which does similar things and limits them to the 
> module it is used in. I would be curious to hear about your results.
> 
> Kind regards, Roald

Hi,
well, i have thought on the issue and i think that i have found a 
solution that does not imply renaming the keywords. It mixes a bit the 
suggestions i got here and this is how.

My application will have a text editor (with, hopefully, code 
highlighting) a text-box to insert "instant" commands and a text-box for 
the output and a window for the "turtle".

With the "instant commands" you can insert little pieces of python code 
and see instantly their result both as a turtle movement or textual 
output. With the text-editor you can load/save/write whole python 
programs and execute or debug them step by step.

The way to track the code could use this technique 
http://www.dalkescientific.com/writings/diary/archive/2005/04/20/tracing_python_code.html 
which gives me exactly the number of line of code under execution and 
also stops the code until the function "treaceit" returns. This will 
allow me to insert breakpoints, execute the code line by line, and so on 
(or at least this is the theory).

Now. Since i get the number of the line i don't need anymore to have the 
language deal with translated keywords. The kid can write the code in 
his/her own language and the program will "translate it back to english" 
before passing them to the embedded python. When i save a source file i 
can save the english version and translate it "on the fly" when i load 
it. I can also intercept error codes and translate them as well, showing 
the kid only what i want him/her to see. So it would be completely 
transparent to the kid and it would notice it only by opening the source 
code via a different text-editor. In this way the files produced are 
100% python files and the kid can disable this feature if he doesn't 
like it. This will also allow me to translate the same piece of code in 
any language i want, with 0 effort and this way will allow kids of 
different nations exchange their code and have it working on their computer.

This seems a good idea to me, it reaches my points without breaking 
compatibility. The kid will see the language in his own language but the 
computer will actually work with the standard-python file.

Once i have this "ready" i can proceed to other steps and try to 
implement other ideas that i have (remember c-robots and p-robots?).

Bye,
   Luca



More information about the Python-list mailing list