What are the advantages of Lua over other scripting languages for a TeX implementation?

I have been coding "PythonTeX" since last May, and am planning the first public release sometime between next weekend and the beginning of March. I'm actually planning to call it PythonTeX, by analogy to PerlTeX and SageTeX.

I've created a LaTeX package, and accompanying Python scripts, that provide most functionality of python.sty, SageTeX, and SympyTeX, but with emphasis on speed and usability. Here's a brief summary of what PythonTeX will bring.

• Persistence between commands and environments. For example, each environment \begin{pythoncode} ... \end{pythoncode} picks up where the last left off, so all variables, functions, etc. persist. You can optionally name commands and environments, and then there is only persistence between commands and environments with the same name. For example, \begin{pythoncode}[name] ... \end{pythoncode} only shares persistence with other commands and environments called name.

• Automatic inclusion of printed content. For example,

  \begin{pythoncode}
  print(1+1)
  \end{pythoncode}
  

  is automatically replaced by 2 in the compiled document.

• Speed. Each set of named commands and environments is executed in its own process, using Python's multiprocessing package. Also, each set is hashed, so code is only executed when changed. The results of running the code are saved, and reused when no changes are detected.

• Code typesetting. All code that is executed can also be typeset, using fancyvrb and its internals. Optionally, code can be typeset using Pygments, which is a Python package that does syntax highlighting (Pygments is used by the minted package). When Pygments is used, all code is hashed and the typeset results are saved, so that only changed code must be processed by Pygments in subsequent runs. This helps prevent Pygments from slowing things down.

• Meaningful error messages. All error messages are parsed by code that determines the line of your document where the error occurred (as opposed to the line of the *.py file that is actually executed). So you know exactly where things went wrong in your document.

• Minimal files. The code cleans up after itself, so the number of permanent files created by Python is kept to a minimum and all temporary files are deleted after each run.

I can post a link as soon as PythonTeX is released. I will also be submitting it to CTAN shortly after the first public release.

The LuaTeX developers have commented on their choice of Lua over other languages, including Python, on their home page.

Embedding the interpreter is one thing, and apparently no fun with Python. Another is to actually make the innards of TeX visible to the embedded interpreter. While much of the communication code could likely be adapted in some way from LuaTeX to PythonTeX, it will still be a lot of work.

A better approach may be to cheat a bit, and simply piggyback on the LuaTeX interpreter. There is a bridge that 'embeds' Python inside Lua called Lunatic Python, and maybe it can be made to work with LuaTeX also. However, it may be easier to just use XML-RPC: Let LuaTeX spawn a Python process, which acts as the XML-RPC server. LuaTeX commands can then make calls to the Python process. Bonus feature: Once this is implemented on the LuaTeX side, it can be used with any other scripting language, not just Python.

My take is: Lua as a language was created as an embedded language and is well suited for the job. Now that with LuaTeX a scriptable TeX implementation exists, there is little principled reason to create another one. Of course, you can go ahead and create PythonTeX. But it seems that the community feels that this would not add enough value over LuaTeX to justify the cost.