An 'interpreter per thread' [...] your memory foot print [...] limits the number of concurrent requests the server can handle
So, in this situation, it would be useful for the interpreter to be lightweight in terms of RAM usage as well as code size. Presumably, though, it is still not necessary to be as frugal as MicroPython, which can get by with as little as 8KB of RAM and is commonly used with 128KB [1]?
A lot of people who use python would expect your implementation to act like the mainline. [...] it would almost be better to create a new language than to always be explaining "no, that functionality doesn't work" [...] just don't call it [Python]
In order to work within tens of kilobytes of RAM, MicroPython does some things differently from CPython [2]. I wonder if its developers spend much time explaining the differences between the two implementations? Or do users expect differences in the language runtimes because of the obvious differences in the hardware on which they run?
On the other hand, I imagine MicroPython would have significantly fewer users if it were advertised as "a Python-like language" rather than as "an implementation of Python".
What advantages would you see your Python implementation having over Tcl or Lua which were designed with this area in mind?
Python is a much more popular language than Tcl or Lua. Embedding Python opens your application to scripting by many more people, because the average person wanting to write a script is more likely to be familiar with it. Even those familiar with multiple languages may prefer to use Python - Tcl and Lua are often considered to be slightly "quirky" languages.
Also, although an embedded Python interpreter is never going to run C libraries like NumPy, there are many pure-Python libraries out there which would potentially be available for scripts to use.
The main feature I would like to see is a commitment for long term support and maintenance.
How would such a commitment be demonstrated? Which existing projects have done a good job convincing you of their longevity?
What does lightweight actually mean?
I would like to make it possible to embed Python within your application without significantly increasing its size. For example, a standalone implementation of Lua is around 500KB, and of mruby is around 700KB. I would consider both of these to be "lightweight" - they could be embedded just about anywhere.
CPython 3.5, however, is closer to 4MB in size - large enough that embedding it would significantly increase the size of smaller applications. PyPy is much larger still, at around 40MB.
On the other hand, I intend for my implementation to target desktop and mobile applications, so am not too concerned about RAM usage at runtime. This contrasts with MicroPython, which targets microcontrollers with limited memory and is therefore designed "to minimise RAM usage" [1].
So, in this situation, it would be useful for the interpreter to be lightweight in terms of RAM usage as well as code size. Presumably, though, it is still not necessary to be as frugal as MicroPython, which can get by with as little as 8KB of RAM and is commonly used with 128KB [1]?
A lot of people who use python would expect your implementation to act like the mainline. [...] it would almost be better to create a new language than to always be explaining "no, that functionality doesn't work" [...] just don't call it [Python]
In order to work within tens of kilobytes of RAM, MicroPython does some things differently from CPython [2]. I wonder if its developers spend much time explaining the differences between the two implementations? Or do users expect differences in the language runtimes because of the obvious differences in the hardware on which they run?
On the other hand, I imagine MicroPython would have significantly fewer users if it were advertised as "a Python-like language" rather than as "an implementation of Python".
[1] https://github.com/micropython/micropython/wiki/FAQ
[2] https://github.com/micropython/micropython/wiki/Differences